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ABSTRACT 


The  intent  of  this  thesis  is  to  gain  insight  into  launch  and  test  range  requirements 
in  order  to  determine  transitional  architectures  by  using  a  systems  engineering 
methodology  developed  at  the  Naval  Postgraduate  School.  The  range  is  a  weapon  system 
that  has  many  characteristics  of  an  automated  information  system  with  each  function 
having  its  own  timing  and  bandwidth  requirements.  The  sensors  considered  are  those  left 
after  the  range  begins  using  GPS  metric  tracking  for  all  launch  vehicles.  The  analysis 
focuses  on  comparing  the  use  of  current  data  formats  to  an  Internet  Protocol  version  6 
(IPv6)  standard  by  considering  data  availability  and  timeliness  as  design  parameters. 
Sensors  should  be  compatible  with  the  data  network  rather  than  with  legacy  formats  since 
data  is  not  transported  in  the  legacy  formats.  Devices  requiring  a  legacy  format  need  a 
converter  to  consume  data  from  the  network.  The  analysis  is  an  accounting  of  throughput 
required  at  various  nodes  on  the  data  network  and  estimates  of  data  latency  along  critical 
data  links.  The  conclusion  is  that  the  current  range  architecture  is  able  to  support  GPS 
metric  tracking  and  that  an  IPv6  network  is  a  viable  option  that  moves  the  range  toward 
compliance  with  the  Operational  Requirements  Document. 
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I.  INTRODUCTION 


A,  BACKGROUND 

The  United  States  Air  Force  is  responsible  for  operating  and  sustaining  the 
nation’s  Spacelift  Ranges.  They  are  the  Eastern  Range  (ER)  in  Elorida  with  launch 
complexes  at  Cape  Canaveral  and  Kennedy  Space  Center,  and  the  Western  Range  (WR) 
with  launch  complexes  at  Vandenberg  Air  Eorce  Base.  Together,  the  ER  and  WR 
comprise  the  current  Eaunch  and  Test  Range  System  (ETRS). 

The  Eastern  Range  is  operated  by  the  Air  Eorce’s  45th  Space  Wing  (45  SW),  and 
the  30th  Space  Wing  (30  SW)  operates  the  Western  Range.  Space  Missile  Systems 
Center  (SMC)  is  responsible  for  both  sustainment  and  new  acquisitions.  These 
responsibilities  have  been  assigned  to  the  Eaunch  and  Ranges  Range  Group  under  the 
Eaunch  and  Range  Systems  Wing. 

The  primary  mission  of  the  ETRS  is  to  support  both  routine  and  responsive 
spacelift  for  DoD,  other  US  government  agencies  (NASA,  NOAA  and  intelligence 
community)  and  commercial  interests.  The  secondary  and  tertiary  missions  are  Test  and 
Evaluation,  and  supporting  the  Space  Surveillance  Network  (SSN)  respectively. 

1.  Eastern  Range 

The  45th  Space  Wing,  headquartered  at  Patrick  Air  Eorce  Base  (PAEB),  conducts 
spacelift  and  missile  test  operations  at  the  ER  on  the  central  east  coast  of  Elorida  (see 
Eigure  1). 
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ER  instrumentation  sites  are  loeated  at  NASA’s  Kermedy  Space  Center  (KSC), 
Cape  Canaveral  Air  Force  Station  (CCAFS),  PAFB,  Melbourne  Beach  Optical  Tracking 
Annex,  Malabar  Annex,  Jonathan  Dickinson  Missile  Tracking  Annex  (JDMTA),  Antigua 
Air  Station  in  the  eastern  Caribbean  Sea,  and  Ascension  Auxiliary  Airfield  in  the  South 
Atlantic  Ocean.  For  North  Easterly  space  launches,  the  ER  extends  north  to  New 
Hampshire  Tracking  Station  and  Argentia  in  Newfoundland,  Canada,  and  includes  a 
midpoint  location  at  Wallops  Islands,  Virginia  (NASA  facility).  Eaunch  sites  on  KSC 
and  CCAFS  are  capable  of  supporting  most  launch  azimuths  from  34°  to  112°  with  some 
excluded  for  safety  restrictions. 

2,  Western  Range 

Headquartered  at  Vandenberg  Air  Force  Base  (VAFB),  the  30th  Space  Wing 
conducts  spacelift  and  missile  test  launches  at  the  WR  on  the  central  coast  of  California 
(Figure  2). 
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WR  instrumentation  sites  are  located  along  the  Pacific  coast  at  Pillar  Point  Air 
Force  Station,  VAFB,  Anderson  Peak,  Santa  Ynez  Peak,  Laguna  Peak,  and  Point  Mugu. 
The  WR  supports  southern  trajectory  space  launches  capable  of  achieving  polar  orbits. 
Launch  sites  on  VAFB  are  capable  of  supporting  launch  azimuths  from  147°  to  286°.  In 
conjunction  with  other  Major  Range  and  Test  Facility  Base  (MRTFB)  activities,  the  WR 
provides  continuous  instrumentation  coverage  for  ballistic  missile  test  launches  into 
target  areas  in  the  Pacific  Ocean.  Additionally,  the  WR  provides  operational  support  for 
the  West  Coast  Offshore  Operating  Area  (WCOOA),  creating  an  aeronautical,  and  guided 
and  unguided  missile  test  corridor  along  the  Pacific  coast  from  the  Mexican  to  the 
Canadian  borders.  The  WR  supports  satellite  launches  into  polar  orbits,  intercontinental 
ballistic  missile  tests.  Missile  Defense  Agency  (MDA)  activities,  and  aeronautical  tests. 
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3. 


Future  Range  Architectural  Planning 


The  Future  Range  Arehiteeture  Team  (FRAT)  was  assembled  to  provide  a  range 
roadmap  that  moves  from  the  eurrent  range  arehiteeture  to  a  vision  for  2020.  The  team 
ineluded  representatives  from  Headquarters  Air  Foree  Spaee  Command  (operations  and 
requirements  direetorates),  Launeh  and  Ranges  Systems  Wing,  30th  Spaee  Wing,  45th 
Spaee  Wing,  Aerospaee  Corporation,  and  ENSCO. 

The  lynehpin  of  the  FRAT’s  proposed  arehiteeture  is  a  net-ready  infrastrueture 
built  on  the  Internet  Protoeol  version  6  (IPv6)  standard,  whieh  is  interoperable  with  the 
DoD  information  sharing  environment  known  as  the  Global  Information  Grid  (GIG). 
This  would  replaee  the  eurrent  Cellworx®  eore  with  a  modern  and  sustainable 
eommunieations  network. 

Sinee  the  time  the  FRAT  developed  their  proposal,  eonsiderable  budget  euts  were 
projeeted.  The  eommander  of  Air  Foree  Spaee  Command  eharged  the  Launeh  Enterprise 
Team  (LET)  with  finding  potential  savings  in  the  launeh  enterprise.  Sinee  then,  the 
vision  of  the  range  arehiteeture  has  been  the  subjeet  of  vigorous  debate. 

B,  PURPOSE 

The  intent  of  this  thesis  is  to  gain  insight  into  LTRS  requirements  for  determining 
reasonable  transitional  arehiteetures. 

Currently  the  Spaeelift  Ranges  use  a  strategy  of  aequiring  modern  instrumentation 
and  making  it  baekward  eompatible  to  the  eurrent  range  infrastrueture.  This  approaeh 
was  a  driver  in  the  eost  and  eomplexity  of  employing  the  Massaehusetts  Institute  of 
Teehnology  Lineoln  Laboratory  (MIT-LL)  developed  radar  known  by  the  aeronym 
ROSA,  whieh  stands  for  Radar  Open  Systems  Arehiteeture.  Bringing  ROSA  to  the 
Spaeelift  Ranges  required  elaborate  interfaeing  to  slow  the  data  and  eonform  to  the 
legaey  data  frames  in  order  to  interfaee  with  the  eurrent  range  infrastrueture.  Other 
instrumentation  modernization  efforts  are  underway  and  they  will  likely  have  a  number 
of  baekward  eompatibility  requirements.  Determining  how  to  break  out  of  the  baekward 
eompatibility  mode  gives  rise  to  the  researeh  questions  posed  in  this  thesis. 
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Since  the  range  needs  to  eontinue  to  support  operations  during  the  transition,  there 
may  be  interim  hybrid  configurations  used  during  the  evolution.  Perhaps  a  hybrid  range 
eonsisting  of  various  sub-networks  of  net-ready  sensors  made  backward  compatible  as  a 
group  is  more  effective.  Perhaps  a  modernized  range  will  be  built  alongside  the  legaey 
range  with  sensors  feeding  both  the  legacy  and  modem  networks.  After  a  series  of  dual 
mode  operations  the  legaey  network  can  be  turned  off. 

C.  RESEARCH  QUESTIONS 

Question  1 :  Should  the  Spaeelift  Ranges  migrate  their  data  networks  to  an  IPv6 
standard  as  proposed  by  the  Future  Range  Arehiteeture  Team? 

Question  2:  In  modernizing  the  range  data  network,  is  it  more  advantageous  to 
make  legaey  components  forward  compatible  or  to  make  modern  eomponents  backward 
compatible? 

D.  BENEFITS  OF  STUDY 

This  study  proposes  eriteria  and  methodology  to  evaluate  different  range  network 
configurations  and  data  flow  schemes.  The  eriteria  are  data  availability,  which  is  whether 
the  network  has  the  capaeity  to  transport  the  required  data,  and  timeliness,  whieh  is 
whether  the  data  transport  is  done  within  the  allowable  time.  The  method  for  evaluating 
availability  is  to  determine  the  required  volume  of  data  and  compare  it  to  the  capaeity  of 
the  network  switches  and  data  links.  The  methodology  for  evaluating  timeliness  is  to 
determine  the  lateney  of  various  data  links  by  adding  the  latency  of  each  step  of  the  data 
transport  process.  The  intended  benefit  is  to  give  decision  makers  a  framework  for 
considering  the  merits  of  projects  that  evolve  the  range  to  the  planned  future  arehiteeture. 

E.  SCOPE  AND  METHODOLOGY 

This  thesis  proposes  interim  configurations  that  the  Eastern  Range  might  assume 
during  its  evolution.  The  eandidate  interim  configurations  are  eonsistent  with  the  visions 
of  the  LET  in  that  the  range  footprint  reflects  its  plan  with  different  networking  schemes. 
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The  candidate  configurations  are  retaining  the  current  network  or  upgrading  it  according 
to  the  FRAT  plan.  Operational  scenarios  are  identified  and  the  candidate  configurations 
are  evaluated  in  terms  of  system  design  parameters. 

F.  ORGANIZATION  AND  SUMMARY  OF  STUDY 

1.  Background  Information 

This  thesis  begins  with  a  discussion  of  the  strategy  for  gathering  background 
information  for  the  analysis.  Broad  topic  areas  are  identified  along  with  a  discussion  of 
potential  sources  of  information.  The  basic  topic  areas  are  1)  systems  engineering 
methodology,  2)  range  requirements,  3)  Eastern  Range  architecture,  4)  Eastern  Range 
operational  configurations,  and  5)  communications  networks.  The  strategy  discussion  is 
followed  by  a  summary  of  the  information  gathered.  The  information  is  grouped  in  the 
same  topic  areas. 

2,  Analysis  and  Results 

The  analysis  of  the  candidate  configurations  and  the  results  are  organized  as  a 
discussion  of  how  each  step  of  the  system  engineering  methodology  is  applied  to 
studying  the  Eastern  Range.  The  analysis  focuses  on  comparing  the  current  network 
structure  to  a  proposed  network  based  on  an  IPv6  standard.  The  design  parameters  are 
availability  and  timeliness.  Both  of  these  are  judged  from  a  range  safety  perspective. 

Availability  is  considered  in  terms  of  the  network  capacity  to  move  all  of  the 
required  data.  A  throughput  model  is  used  to  determine  how  much  bandwidth  is 
required.  Timeliness  requirements  are  established  to  meet  the  range  safety  requirements. 
Timeliness  is  evaluated  by  considering  the  data  latency  introduced  as  the  data  flows 
through  the  network.  The  results  of  this  analysis  are  considered  in  terms  of  how  range 
systems  are  made  to  be  interoperable  with  the  network  and  how  that  interoperability 
might  be  achieved. 
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3. 


Conclusions  and  Recommendations 


The  range  is  generally  eonsidered  a  weapon  system  sensor  network  and  is  often 
viewed  as  a  hub  and  spokes  topology  with  an  operations  eenter  at  the  hub  and  the  sensors 
on  the  spokes.  Another  point  of  view  useful  for  determining  range  functional 
requirements  is  one  that  considers  the  range  as  an  Automated  Information  System  (AIS) 
where  data  comes  on  to  a  network  and  consumers  access  it.  This  viewpoint  focuses  on 
the  core  network,  which  would  be  the  hub  from  the  sensor  net  point  of  view.  Both 
viewpoints  reflect  functions  the  range  needs  to  perform.  Each  function  has  its  own 
timing  and  availability  (bandwidth)  requirements  that  converge  on  the  core  network;  the 
data  network  thus  needs  to  be  the  focus  of  architectural  decisions.  In  particular,  the 
sensor  interfaces  need  to  be  defined  for  compatibility  with  the  data  network  rather  than 
with  legacy  data  formats,  which  are  incompatible  with  the  data  network. 

The  current  range  network  has  the  bandwidth  for  the  network  traffic  required  to 
function  as  a  sensor  network  and  as  an  Automated  Information  System.  The  limiting 
factor  for  the  network  is  the  data  link  to  JDMTA.  This  link  is  especially  important 
because  all  GPS  metric  tracking  data  is  processed  at  JDMTA.  The  GPS  data  is  contained 
in  the  telemetry  stream.  At  this  point,  the  telemetry  stream  needs  to  be  divided,  so  only 
the  portion  carrying  the  GPS  data  is  sent  for  processing  at  JDMTA.  The  commercial 
leased  lines  do  not  have  the  capacity  to  handle  the  entire  telemetry  stream.  Another 
network  traffic  flow  that  is  worth  considering  is  the  data  link  to  the  telemetry  site  TEL 
IV.  TEL  IV  is  the  where  the  telemetry  streams  are  evaluated  to  determine  which  stream 
to  provide  to  the  range  customer.  Both  the  current  network  and  an  IPv6  based  network 
can  meet  the  timeliness  requirements  for  range  safety.  The  biggest  source  of  data  latency 
comes  from  packaging  data  into  cells  for  transport  on  the  network.  The  IPv6  network 
would  require  data  to  be  sent  in  IP  packets.  The  time  needed  for  either  operation  is 
dependent  on  the  rate  data  flows  into  the  device  that  packages  it  because  the  cells  (or 
packets)  cannot  be  assembled  until  the  entire  data  frame  is  received.  This  makes 
adherence  to  legacy  data  standards  (240-bit  data  frames  transported  at  2.4  or  4.8  Kbps)  a 
significant  source  of  latency. 
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Sensors  should  be  built  to  be  eompatible  with  the  data  network  rather  than  with 
the  data  rate  and  format  of  the  deviee  eonsuming  the  data.  Sinee  data  is  not  transported 
on  the  network  in  the  legaey  data  formats,  any  deviee  that  requires  a  legaey  data  format 
must  have  a  eonverter  to  eonsume  data  from  the  network.  Requiring  new  sensors  to 
output  a  legaey  data  format  means  that  output  has  to  be  eonverted  to  a  eell  (or  paeket)  for 
it  to  be  sent  on  the  data  network.  If  the  sensor  eould  have  output  data  in  a  form 
eompatible  with  the  network,  the  steps  required  to  produee  the  legaey  format  add 
unneeessary  complexity  and  latency. 

The  current  range  architecture  seems  able  to  support  a  move  to  GPS  metric 
tracking.  Additionally,  this  analysis  concludes  that  an  IPv6  based  range  data  network  is  a 
viable  option  that  moves  the  range  toward  compliance  with  the  Operational  Requirements 
Document  (ORD).  However,  supportability  and  interoperability  are  significant  factors  in 
choosing  an  architecture.  Consideration  of  those  factors  is  beyond  the  scope  of  this 
thesis. 
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II.  RESEARCH 


A,  INTRODUCTION 

Learning  about  the  Spacelift  Ranges  proved  to  require  a  great  deal  of  researeh. 
Studying  a  few  doeuments  led  to  asking  people  questions,  whieh  in  turn  generated 
referrals  to  various  experts.  The  experts  often  reeommended  studying  other  doeuments, 
drawing,  and  handbooks,  whieh  lead  to  more  questions  and  so  on. 

Creating  a  system  of  systems  out  of  the  range  assets  is  largely  a  matter  of 
networking.  The  range  network  is  the  foeus  of  this  analysis. 

B,  METHODOLOGY 

The  researeh  methodology  is  to  review  published  work  that  deseribes  and 
diseusses  applieation  of  a  systems  engineering  methodology  developed  at  the  Naval 
Postgraduate  Sehool  (Osmundson  &  Huynh,  2005).  The  next  area  of  investigation  is  the 
range  requirements.  Sinee  the  range  is  an  Air  Foree  aequisitions  program,  requirements 
are  formally  doeumented.  Interviews  with  range  engineers  and  operators  give  additional 
insight  into  the  requirements.  These  sources  and  range  operational  capability  documents 
provide  information  on  the  current  range  architectures.  Current  thinking  on  the  future  of 
the  range  architecture  is  revealed  in  presentations  given  by  various  groups  working  in  Air 
Force  Space  Command.  Interviews  are  another  valuable  source  of  information. 

Another  research  objective  is  to  gain  an  understanding  of  information  networks. 
This  is  done  by  reviewing  journal  articles,  range  operator  training  materials,  industry 
standards,  and  through  conducting  interviews. 

C,  RESEARCH 

1.  Systems  Engineering 

A  practical  method  of  analyzing  a  system  of  systems  is  espoused  in  (Osmundson 

&  Huynh,  2005).  This  method  applies  effectively  to  the  Spacelift  Ranges  since  it  is 
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concerned  with  systems  that  have  been  developed  and  still  funetion  as  standalone 
systems.  It  is  well  suited  to  systems  sueh  as  the  Spaeelift  Ranges  whose  success  is 
dependent  on  process  timeliness.  The  method  involves  a  sequenee  of  analyses,  modeling, 
and  simulations.  The  seven  steps  of  the  method  are  as  follows: 

•  Development  of  system  of  systems  seenarios  and  operational  architeetures 

•  Identifieation  of  system  of  systems  threads 

•  Representation  of  operational  architeetures  in  a  unified  modeling  language 
(UML)-like  format 

•  Identifieation  of  systems  of  systems  design  parameters  and  factor  levels 

•  Transformation  of  UML-like  format  representation  into  executable  models 

•  Application  of  design  of  experiments 

•  Simulation  runs  and  analysis  of  results 

2.  Range  Requirements 

The  range  requirements  are  captured  in  the  Operational  Requirements  Doeument 
(ORD)  (Headquarters  Air  Foree  Spaee  Command,  DRDS,  2003).  Particular  attention  is 
given  to  interoperability  as  diseussed  in  Section  1.4.3  Command,  Control, 
Communications,  Computer,  Intelligence,  Surveillance,  and  Reeonnaissance  (C4ISR) 
Operational  Concept.  The  ORD  offers  an  operational  view  1  (OV-1)  of  the  LTRS  listing 
the  wide  variety  of  agencies  and  supporting  ranges  that  need  to  interface  with  the 
Spaeelift  Ranges  and  the  connections  that  join  the  range  subsystems  together  to  create  a 
system  of  systems.  The  ORD,  again  from  Section  1.4. 3. 3,  specifies  that  the  LTRS  must 
have  interfaces  for  connectivity  to  digital  and  analog  information  links,  satellite  and  voice 
communications  circuits.  Additionally,  the  LTRS  must  operate  within  the  DoD 
information  sharing  environment  known  as  the  Global  Information  Grid  (GIG). 

3.  Range  Architecture 

Deliberations  on  the  range  architecture  seem  to  eenter  on  the  number  and 
placement  of  what  this  analysis  called  the  end  items,  which  are  the  sensors  necessary  to 
perform  the  range  tracking  functions.  The  evolution  of  the  range  arehitecture  is  also 
discussed  in  terms  of  two  maturing  concepts  that  may  ehange  the  way  range  functionality 
is  achieved. 
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Starting  with  a  review  of  the  range  funetion,  the  FRAT  (FRAT,  2007)  identities 
the  required  funetionality  as: 

•  Flight  Control  (eommand  destruet,  flight  operations,  flight  analysis, 
vehicle  control) 

•  Space  vehicle  (SV)/launch  vehicle  (LV)  health  and  status  (performance, 
telemetry) 

•  Tracking  (debris,  launch  vehicle  position,  staging  events) 

•  Imaging  (documentary — media,  public  affairs,  engineering  analysis,  event 
reconstruction) 

•  Command,  Control,  Communication  and  Timing-C3T  (voice,  data, 
video,  timing,  range  operations  management) 

•  Data  Handling  (data  products,  planning  and  scheduling) 

•  Area  Surveillance  (detection  &  assessment  of  air,  sea,  and  rail 
encroachments) 

•  Weather  (observation,  analysis,  forecasting) 

The  functions  whose  evolution  will  most  impact  the  range  footprint  (end  item 
assets)  are  Tracking  and  Flight  Control,  particularly  the  command  destruet  part  of  Flight 
Control. 

In  the  near  future,  GPS  metric  tracking  will  be  utilized  on  a  number  of  launch 
vehicles.  Currently  the  GPS  data  is  received  on  a  telemetry  stream,  and  so  is  the  Inertial 
Guidance  System  (IGS)  data.  They  fulfill  the  requirement  of  having  two  independent 
sources  of  metric  tracking  data.  Radar  and  optics  (on  the  Eastern  Range  at  least)  are  also 
viable  sources  of  metric  track  data.  As  GPS  tracking  is  fully  implemented,  radar  and 
optics  will  no  longer  be  considered  range  safety  mandatory  and  will  instead  provide 
imaging  data  and  back  up  tracking  data,  as  well  as  debris  tracking. 

Another  concept  that  will  shape  the  range  is  the  evolution  of  Autonomous  Flight 
Termination  Systems  (AFTS).  Flight  termination  is  currently  done  with  a  person  in  the 
loop.  The  tracking  data  is  displayed  for  a  person  to  consider  in  determining  whether  to 
command  the  vehicle  to  destruet.  The  commands  are  sent  using  ground  based 
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antennas  at  a  variety  of  points  along  the  range.  When  AFTS  are  used  on  every  roeket 
launehed,  the  range  can  divest  the  ground  based  command  systems  and  possibly  the 
systems  that  generate  metric  tracking  data. 

a.  Range  Sensors 

The  number  and  the  placement  of  range  sensors  are  often  the  focus  of 
discussion  about  the  range  architecture.  A  list  of  the  current  range  assets  is  shown  in 
Table  1,  which  depicts  a  distinction  between  enabling  equipment  necessary  for  end  items 
(sensors)  to  operate  as  part  of  the  range  system.  For  example,  the  radars  and  telemetry 
sites  are  end  items  that  directly  result  in  range  capability  to  cover  a  particular  mission. 
The  communications  infrastructure  and  items  like  voice  communications  are  all 
necessary,  irrespective  of  the  number  of  end  items  because  they  enable  the  subsystems  to 
be  joined  into  the  range  system.  Table  1  shows  the  FRAT  and  LET  assets  considered 
necessary  while  working  under  the  assumption  that  GPS  metric  tracking  would  replace 
radar  as  a  range  safety  metric  tracking  source.  The  LET  went  on  to  develop  preliminary 
planning  concepts  for  a  range  using  AETS. 

In  Table  1  ‘X’  indicates  equipment  (rows)  used  in  the  given  plan 
(columns)  and  ‘D’  denotes  assets  to  be  divested.  Enabling  equipment  lines  are  grey. 


Table  1 .  Eastern  Range  Assets  Under  Various  Plans 


Current 

Enabler  End  Item 

FRA 

T 

block 

1 

End 

Item 

LET 

Pre  GPS 

LET 

GPS 

AFTS 
used 
End  Item 

ADD  GPS  metric  tracking 

X 

X 

X 

_l 

1.16 

X 

D 

X 

D 

Q 

Q. 

19.39  (MOTR) 

X 

X 

D 

D 

m 

u. 

19.17 

X 

D 

X 

D 

< 

CL 

19.14 

X 

X 

D 

D 

o 

0.14 

X 

X 

X 

X 

Uj 

SPARC 

X 

CO 

ll 

FCA  Control 

X 

< 

o 

FCA  Van  #1 ,2 

X 

o 

TAA-3C 

X 

X 

X 

X 

X 
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Current 

Enabler  End  Item 

FRA 

T 

block 

1 

End 

Item 

LET 

Pre  GPS 

LET 

GPS 

AFTS 
used 
End  Item 

TAA-24A 

X 

X 

X 

X 

X 

AFSCN  Data  Distribution 

X 

Data  Acquisition  and  Processing 

X 

Display 

X 

Record 

X 

Separation 

X 

DTPS 

X 

TRG 

X 

9M-1,2 

X 

4.3M 

X 

ACME 

X 

CAPE  1B 

X 

X 

X 

X 

D 

CAPE  1A 

X 

X 

X 

X 

D 

CCRS 

X 

Analog  Voice 

X 

Cable  Plant  and  Conditioning 

X 

Commercial  Leased  Lines 

X 

Digital  Voice-XY 

X 

NASCOM 

X 

Wideband 

X 

CORE 

X 

Data  Transmission 

X 

Digital  Voice 

X 

Intelsat  SATCOM 

X 

M365  INMARSAT 

X 

Microwave 

X 

TMS 

X 

AMP  S-A,B 

X 

MSC 

X 

DBS 

X 

DRSD 

X 

FOV1-A,B 

X 

RSAS 

X 

Count,  Timing,  and  Control 

X 

ATOTS  1 ,2 

X 

X 

X 

X 

X 

MIGOR 

X 

X 

X 

X 

X 

C/5 

O 

CINE  401-403 

X 

D 

X 

D 

D 

Q. 

o 

CINE  404-407 

X 

D 

D 

D 

D 

Playalinda  DOAMS 

X 

X 

X 

X 

X 

PAFB  DOAMS 

X 

X 

X 

X 

X 

Q  $ 

28.14 

X 

E  S 

D 

D 

D 

—  CC 

UJ  c 

TAA-50-1  X  XX  moved 
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Current 

Enabler  End  Item 

FRA 

T 

block 

1 

End 

Item 

LET 

Pre  GPS 

LET 

GPS 

AFTS 
used 
End  Item 

CCAFS 

TAA-50-2 

X 

X 

X 

moved 

CCAFS 

TAA-50-3 

X 

X 

X 

Eliminate 

TAA-50-4 

X 

X 

X 

ACME 

X 

COMMAND 

X 

X 

X 

Cable  Plant  and  Conditioning 

X 

CORE 

X 

Data  Transmission 

X 

Microwave 

X 

TMS 

X 

TORS  (GPS  tracking) 

X 

X 

X 

moved 

CCAFS 

Count  and  Timing 

X 

Antigua/St.  Thomas 

91.14 

X 

D 

D 

D 

D 

91.134 

X 

D 

D 

D 

D 

TAA-3C 

X 

X 

X 

X 

X 

TAA-8A 

X 

X 

X 

X 

X 

ACME 

X 

COMMAND 

X 

X 

D 

D 

D 

Cable  Plant  and  Conditioning 

X 

CORE 

X 

Data  Transmission 

X 

Digital  Voice 

X 

Intelsat  SATCOM 

X 

TMS 

X 

Count  and  Timing 

X 

Argentia 

53.17 

X 

Support  with 
mobiles 

Support  with 
mobiles 

Support  with 
mobiles 

Eliminate 

ACME 

X 

COMMAND 

X 

Data  Transmission 

X 

Cable  Plant  and  Conditioning 

X 

TMS 

X 

Station  Count  and  Timing 

X 

ASC 

12.18 

X 

D 

D 

D 

D 

12.15 

X 

X 

X 

X 

X 

TAA-3C-1 

X 

D 

D 

D 

D 

TAA-3C-2 

X 

D 

D 

D 

D 

Station  Count  and  Timing 

X 
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b.  Range  Network 


The  FRAT  plan  for  the  range  arehiteeture  looks  beyond  the  end  item 
assets  to  focus  on  the  data  network.  It  proposes  an  architecture  built  on  an  IPv6  network 
ring  that  would  allow  the  range  to  be  DoD  GIG  complaint.  GIG  compliance  is  an  ORD 
requirement  found  in  Section  1.4. 3. 3.  The  FRAT  presents  GIG  compliance  as  one  of  the 
pillars  of  their  Block  1  architecture.  The  five  pillars  are:  1)  comply  with  the  DoD  Joint 
Technical  Architecture  by  using  IPv6,  2)  become  compatible  with  the  GIG,  3)  use  cluster 
computing,  4)  have  massive  storage  for  high  bandwidth  digital  imaging,  and  5)  provide 
new  software  based  telemetry  receivers  and  recorders  (Slide  20,  FRAT,  2007). 

The  legacy  communications  network  is  largely  based  on  Cellworx® 
switches  which  are  designed  for  use  in  an  asynchronous  transfer  mode  (ATM);  however, 
the  network  is  setup  for  Time  Division  Multiplexing  (TDM)  (Bryant,  2008)  using  circuits 
that  are  static  during  a  launch  operation.  The  Eastern  Range  network  uses  a  ring  topology 
connecting  four  primary  facilities.  The  facilities  are  the  Range  Operations  Control 
Center  (ROCC),  XY  Facility,  Southwest  Terminal  Building  (SWTB),  and  the  East 
Terminal  Building  (ETB). 

The  core  itself  is  shown  as  Ring  1  and  Ring  2  in  the  CCAES  CORE  -  Data 
Elow  illustration  that  is  presented  in  the  Eastern  Range  Instrumentation  Handbook 
(Computer  Sciences  Raytheon,  2008),  shown  in  Eigure  3.  Table  2  explains  the  path 
speeds  (Computer  Sciences  Raytheon,  2008). 


15 


CCAFS  CORE  —  Datd  Flow 


*  Not  all  &RIM  or  Non  ERIH  taciKias  are  raiiTesaned  in  this  diagrain 


Figure  3.  Eastern  Range  Core  Network  (Fig.  1-1  in  Computer  Seiences  Raytheon, 

2008) 


Table  2.  Connection  Speeds  (Table  3.1-1  in  Computer  Sciences  Raytheon,  2008) 


SIGNAL  LEVEL 

DATA  RATE  (Mbps) 

COMMENT 

DS-0 

0.064 

Standard  voice  channel 

DS-1  or  T-1 

1.544 

24  Standard  voice  channels 

DS-3 

44.736 

28DS-1S 

STS-1  (OC-1) 

51.84 

DS-3  with  ATM/SONET  overhead 

OC-3 

155 

3  OC-ls 

OC-1 2 

622 

12  0C-1S 

OC-48 

2488 

48  OC-ls 
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The  core  consists  of  five  subsystems:  1)  ATM  Core,  2)  Core  Access 
Concentrators  3)  Core  Data  Subsystem,  4)  Core  Video  Subsystem,  and  5)  Inverse 
Multiplexers  (IMUX)  (Computer  Sciences  Raytheon,  2008). 

The  core  rings  are  designed  to  be  fault  tolerant  in  that  they  react  to  a  node 
failure  by  routing  the  network  traffic  around  the  ring  in  the  opposite  directions.  The  only 
capability  lost  is  the  ability  to  add  or  remove  data  from  the  core  via  the  failed  node.  The 
Core  Access  Concentrators  are  located  at  each  of  the  nodes  to  adapt  a  variety  of  non- 
ATM  traffic  to  an  ATM  format  for  transfer  onto  the  core  rings.  The  Core  Data  subsystem 
serves  as  an  interface  for  handling  telemetry  data.  The  Core  Video  subsystem  is  capable 
of  digitizing  and  managing  videos  using  the  core  for  transport  to  end  users.  The  IMUX 
subsystem  provides  the  interface  between  the  ROCC  Wide  Area  Network  Interface  Units 
(WANIU)  and  the  JDMTA  WANIU. 

The  Eastern  Range  Instrumentation  Handbook  includes  a  section  on 
limitations  of  the  core.  One  limitation  is  that  the  data  latency  for  the  2.4  Kbps 
synchronous  circuit  is  approximately  60  milliseconds.  Its  impact  is  that  the  ATM  core 
cannot  be  used  to  directly  transport  this  data,  so  it  must  be  aggregated  into  cells 
compatible  with  T-1  circuits  for  transport.  There  is  also  significant  latency  in  the  video 
system.  For  the  5  MHz  bandwidth  rate  the  latency  is  1244  milliseconds,  for  10  MHz  it  is 
827  milliseconds,  and  at  15  MHz  the  latency  is  717  milliseconds  (Computer  Sciences 
Raytheon,  2008). 


c.  Range  Safety  Systems 

The  range  safety  systems  include  the  system  that  processes  and  displays 
metric  tracking  and  telemetry  home  vehicle  performance  data.  They  also  provide  target 
acquisition  data  to  the  command,  telemetry  and  radar  systems.  The  system  that  provides 
for  termination  of  an  errant  vehicle  is  also  a  range  safety  system. 

Flight  Operations  Version  1  (FOVl)  is  the  primary  system  that  processes 

trajectory  source  data.  Two  independent  FOVl  systems,  designated  FOVl-A  and  FOVl- 

B,  are  used.  A  tertiary  processor,  the  Distributed  Range  Safety  Display  (DRSD)  system 

is  included  to  mitigate  the  risk  of  a  latent  software  defect  in  FOVl -A  and  FOVl-B,  which 
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run  the  same  software.  These  systems  generate  flight  path,  predicted  Instantaneous 
Impact  Point  (IIP)  displays,  and  other  displays  that  are  needed  to  determine  the  risk  of 
violating  pre-defined  mission  rules. 

The  FOVl-A  system  also  has  an  additional  Mission  Continuation  Display 
(MCD)  to  monitor  vehicle  performance  and  provide  an  independent,  telemetry  only  IIP 
display.  The  MCD  design  and  programming  language  is  completely  different  from  the 
two  FOVl  systems  as  a  safe  guard  against  software  Single  Points  of  Failure  (SPOF). 

The  FOVl -A,  FOVl-B,  and  DRSD  systems  provide  designate  data  on  the 
High  Density  Data  (HDD)  lines  to  instrumentation  sites  via  the  Data  Buffer  System.  The 
Designate  Source  Select  Switch  (DSSS)  is  used  to  assign  which  system’s  HDD  output  to 
the  remote  sites.  That  decision  is  made  by  the  Acquisition  Data  Processor  (ADP) 
operator. 

Data  frames  are  synchronized  before  entering  FOVl  by  buffering  them  in 
100-millisecond  intervals  (Thomas,  2008).  Radar  and  optics  data  can  be  up  to  one 
second  old  and  telemetry  data  can  be  up  to  1 .2  seconds  old  (Richards,  2008).  Radar  and 
optics  data  frames  include  a  data  bit  known  as  the  “track-bit.”  Additionally  a  quality-bit, 
known  as  a  “Q  bit,”  is  available  to  indicate  that  the  track  is  considered  to  be  of  good 
quality.  FOVl  can  use  data  from  a  source  irrespective  of  the  Q-bit,  but  generally  will  not 
use  data  if  the  Q-bit  is  not  set.  Telemetry  data  quality  is  judged  with  frame 
synchronization  indicators.  The  FOVl  display  operator  has  the  option  of  rejecting  a  data 
source.  This  might  be  done  if  the  data  seems  to  be  “noisy”  or  if  the  sensor  is  under  test 
and  evaluation  (Thomas,  2008). 

FOVl  inputs  are  tabulated  in  Table  3.  Different  sensors  use  different 
coordinate  systems.  Optic  trackers  only  measure  angles,  so  several  trackers  are  needed  to 
generate  a  position  solution  by  triangulating.  The  site  IDs  give  the  FOVl  reference 
points  for  coordinate  transformations. 
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Table  3.  FOVl  Data  Inputs 


FOVl  Data  Inputs 

Radar 

E,  F,  G,  E',  F',  G',  time,  site  ID,  Q-bit,  Track-bit 

Optics 

Azimuth,  elevation,  time,  site  ID,  Q-bit,  Track-bit 

Inertial  Guidance  System  (IGS) 

X,  Y,  Z,  X',  Y',  Z',  time,  site  ID,  Command  receiver  status 

GPS  by  Telemetry 

E,  F,  G,  E',  F',  G',  time 

The  EFG  means  Earth  Eixed  Geodetie,  whieh  uses  a  Cartesian  eoordinate 
system  with  its  origin  at  the  eenter  of  the  earth.  The  axes  are  labeled  E,  E,  and  G  and  the 
veloeity  eomponent  in  the  direetion  of  those  axes  are  labeled  E',  E',  and  G',  respeetively. 
X,  Y,  Z  are  the  axes  of  a  Cartesian  eoordinate  system  whose  origin  is  established  as  the 
IGS  position  on  the  pad  when  the  gyroseopes  are  uncaged  (Thomas,  2008). 

EOVl  can  be  configured  to  display  a  trajectory  determined  by  combining 
all  input  sources  or  a  single  source.  EOV 1  also  displays  the  variable  flight  azimuths  and 
the  predicted  impact  area. 

The  Elight  Termination  System,  also  known  as  the  Command  Destruct 
system,  is  the  means  to  carry  out  a  decision  to  terminate  a  flight  that  violates  the  flight 
safety  parameters.  The  system  is  a  collection  of  ground  based  transmitters  and  antennas, 
a  rocket  borne  receiver,  and  vehicle  destruct  package.  The  system  is  dynamic  in  that  the 
different  ground  stations  transmit  their  destruct  functions  based  on  the  missile’s  position. 
The  active  configuration  of  the  command  subsystem  is  controlled  by  an  operator  assisted 
by  the  Range  Safety  Control  and  Display  (RASCAD)  system,  which  considers  the  site’s 
health  and  status  and  the  missile’s  actual  position  along  with  the  predicted  trajectory. 
The  health  and  the  status  of  the  vehicles  command  destruct  receiver  is  monitored  prior  to 
liftoff  (EO)  when  the  vehicle  begins  using  its  internal  batteries.  At  that  time,  a  command 
signal  is  sent  to  the  vehicle  to  saturate  the  receiver,  so  that  it  cannot  receive  an 
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uncontrolled  signal  that  might  be  taken  as  a  destruct  command.  In  addition  to  the 
jamming  signal,  eheck  tones  are  sent  to  trigger  a  response  of  health  and  status 
information  from  the  receiver. 

The  eommand  system  uses  dedicated  data  links  to  eonneet  Central 
Command,  which  is  the  control  segment  in  the  ROCC,  to  the  launeh  head  eommand  sites 
and  the  XY  building.  Cape  lA  and  Cape  IB  are  the  launeh  head  sites  that  are  conneeted 
with  dedieated  copper  lines  (Smith,  2008a).  All  other  command  sites  are  considered 
down  range.  These  sites  are  Wallops  Island,  JDMTA,  Argentia,  and  Antigua.  Central 
Command  uses  dedicated  secure  copper  lines  to  eonneet  to  the  XY  building  where  the 
eireuit  is  switched  to  the  down  range  data  links. 

The  entire  eommand  system  ineludes  links  besides  the  ones  that  transmit 
the  command  functions.  These  include  voice  communieations  and  timing  links  as  well  as 
designated  data  for  pointing  antennas.  For  these  purposes,  the  command  sites  are  data 
consumers  like  other  range  sites.  The  dedicated  links  create  a  secure  connection  to  the 
launeh  head  command  sites  and  to  the  XY  building.  The  XY  building  is  a 
communications  network  hub.  From  there  a  variety  of  links  are  available  to  the  down 
range  sites.  The  primary  requirement  is  that  there  is  no  single  point  of  failure,  which  is 
achieved  by  using  two  independent  paths.  This  is  usually  a  landline  and  a  satellite 
conneetion,  or  in  the  case  of  JDMTA,  a  microwave  radio  link.  The  command  functions 
are  sent  using  the  range’s  High  Density  Data  format  whieh  is  transmitted  at  a  rate  of  2.4 
Kbps. 

The  eommand  system  may  someday  use  the  common  range  network.  The 
reasons  that  led  to  using  a  dedieated  network  need  to  be  considered  in  any  plans  to  bring 
the  command  system  on  to  the  core  network.  The  current  requirement  is  to  minimize  risk 
(Smith,  2008a).  If  command  were  to  use  the  eommon  network,  engineering  would  need 
to  show  that  the  risk  remains  very  low.  Different  networking  architectures  and  Quality  of 
Service  (QoS)  provisions  are  available  to  ensure  the  delivery  of  command  messages.  In 
faet  the  right  QoS  settings  would  make  the  system  better  able  to  work  if  the  network  were 
under  a  denial  of  serviee  type  attack.  The  properly  marked  eommand  messages  would 
get  through  the  malicious  traffic. 
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4. 


Eastern  Range  Operational  Configurations 


The  typical  range  configuration  varies  depending  on  the  launch  vehicle  and  the 
direction  of  flight.  One  succinct  source  is  found  in  the  ER  Instrumentation  Handbook 
(Computer  Sciences  Raytheon,  2008)  as  a  chart  titled  “Typical  Instrumentation 
Configurations  for  Eastern  Range  Eaunch  Vehicles  and  Elight  Azimuths.”  This  guide  is 
useful  in  determining  which  instrumentation  sites  are  assembled  to  form  the  range 
configuration  for  a  given  operation.  It  is  interesting  to  note  the  dependence  on  Wallops 
Island  for  its  telemetry,  radar  and  command  assets  for  North  Easterly  launches.  Wallops 
Island  is  not  part  of  the  Eastern  Range  baseline.  To  use  the  Wallops  Island  assets  means 
connecting  them  to  the  ER  with  commercially  leased  communications  lines.  When 
choosing  a  configuration  to  model,  one  should  also  consider  the  use  of  mobile  command 
and  telemetry  at  down  range  sites.  This  thesis  will  model  the  range  configuration  used 
for  a  North  Easterly  launch,  which  includes  Wallops  Island  as  a  supporting  range,  and  a 
mobile  command  and  telemetry  system  at  Argentia. 

5.  Communications  Networking 

a.  Publish/Subscribe  Systems 

Publish/Subscribe  (pub/sub)  systems  are  a  key  technology  for  information 
dissemination.  The  basic  functions  of  a  pub/sub  network  are  naturally  publishing  and 
subscribing.  Publishing  submits  a  piece  of  information,  known  as  an  event.  The  action 
of  publishing  an  event  is  called  a  publishing  operation.  The  event  is  generally  structured 
as  a  set  of  attribute-value  pairs,  where  the  attribute  has  a  name  made  up  of  a  simple 
character  string  and  a  type.  The  type  is  one  of  the  common  primitive  data  types  defined 
in  programming  or  query  languages.  A  subscription  is  the  user  expressing  interest  in  data 
in  terms  of  a  set  of  constraints.  These  constraints  are  used  to  filter  events.  An  event  is 
said  to  match  a  subscription  if  it  satisfies  all  the  declared  constraints.  The  verification  of 
whether  an  event  matches  a  subscription  is  called  Matching.  Subscription  models  are 
distinguished  by  the  level  of  expressiveness  they  give  to  the  subscriber’s  interest.  Highly 
expressive  models  lead  to  the  possibility  of  a  precise  match. 
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Any  module  in  a  pub/sub  communications  system  can  take  the  role  of 
Publisher  or  Subscriber.  That  is,  the  module  can  produce  information  (publish)  or 
consume  it  (subscribe).  System  clients  are  not  required  to  communicate  directly  with  one 
another.  The  communications  occur  through  systems  nodes  that  coordinate  themselves  in 
order  to  route  information  from  publisher  to  subscriber.  Participant  decoupling  has 
advantages  such  as  being  able  to  ignore  synchronization  issues  or  direct  addressing  of 
subscribers.  However,  there  are  some  disadvantages.  It  is  very  difficult  to  enforce  any 
end-to-end  QoS  policy  because  of  the  non-deterministic  behavior  of  the  system.  This 
non-determinism  affects  three  fundamental  aspects  of  QoS:  security  (specifically  reliable 
message  delivery),  timely  delivery,  and  trust  relationship.  A  product  discussed  as  being 
good  is  the  Java  Message  Service  (Corsaro,  Querzoni,  Scipioni,  Tucci  Piergiovanni,  & 
Virgillito,  2006).  It  has  the  ability  to  handle  a  message-centric  publish-subscribe  model 
and  it  supports  a  point-to-point  mode. 

Reliable  delivery  is  affected  by  the  various  network  hops  involved  in 
transmissions  over  asynchronous  Wide  Area  Network  channels  or  temporary  node 
overloading.  The  probability  of  receipt  is  increased  with  event  persistence  (stored  in 
memory)  and  with  retransmitted  events. 

Timeliness  is  a  primary  consideration.  Real  time  applications  often  utilize 
a  dedicated  infrastructure  for  the  strict  controls  they  offer  in  order  to  meet  timeliness 
requirements.  Even  in  a  completely  managed  environment  the  pub/sub  system  can  have 
unpredictable  processing  delays  at  the  nodes,  or  it  can  have  routing  anomalies.  If 
timeliness  needs  to  be  closely  controlled,  the  system  should  privilege  point-to-point 
communications.  This  trades  off  the  benefits  of  decoupling.  Decoupling  allows  the 
infrastructure,  rather  than  the  publisher,  to  know  all  the  subscribers.  The  benefit  of  that  is 
the  ability  to  scale  the  network  to  massive  sizes  with  relative  ease. 

Security  and  Trust  considerations  deal  with  both  the  need  to  access  data 
and  assurances  that  the  event  is  not  corrupted  in  route. 
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b.  Data  Distribution  Service  for  Real-time  Systems 

Many  real-time  applications  require  a  pure  data-centric  exchange. 
Applications  requiring  selective  information  exchange  are  good  candidates.  Predictable 
distribution  of  data  with  little  overhead  is  the  primary  goal.  This  can  be  controlled  with 
Quality  of  Service  parameters  that  affect  predictability,  overhead,  and  resource 
utilization.  Distributed  shared  memory  is  a  classic  model,  but  it  is  difficult  to  implement 
efficiently  over  a  network  and  it  is  not  easily  scalable  (Object  Management  Group,  2007). 

D,  SUMMARY 

Several  stakeholders  are  involved  in  any  discussion  of  the  Spacelift  Range 
architecture.  The  Eastern  Range  has  a  number  of  launch  vehicles  to  accommodate,  and 
they  generally  fly  one  of  two  basic  trajectories  (North  East,  or  East).  An  interesting 
model  is  based  on  the  most  taxing  load  on  the  range  network  and  will  have  as  many 
different  assets  as  practical,  spread  over  a  large  geographic  area.  The  point  in  time 
considered  “the  future”  is  the  first  major  step  in  the  range  evolution  that  will  be  defined 
by  the  use  of  GPS  metric  tracking  for  all  vehicles.  GPS  is  currently  used  by  some 
vehicles,  and  the  range  is  equipped  for  this  concept  of  operation.  The  lynchpin  to 
operating  the  range  system  of  systems  is  the  data  network.  A  viable  networking  option 
for  the  range  is  the  Data-Centric  Publish-Subscribe  model,  which  is  used  in  many  real 
time  applications. 
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III.  ANALYSIS  AND  RESULTS 


A,  INTRODUCTION 

The  analysis  presentation  is  organized  to  follow  the  seven-step  methodology 
developed  by  Osmundson  and  Huynh  (2005). 

B,  ANALYSIS 

1.  Development  of  System  of  Systems  Scenarios  and  Operational 
Architectures 

The  Eastern  Range  Capabilities  Doeumentation  (Computer  Sciences  Raytheon, 
2008)  includes  a  chart  titled  “Typical  Instrumentation  Configurations  for  Eastern  Range 
Eaunch  Vehicles  and  Elight  Azimuths”  that  specifies  typical  range  configurations  for  a 
collection  of  vehicles  and  trajectories.  Instrumentation  assets  are  generally  ranked  Range 
Mandatory  (meaning  they  are  a  “must-have”),  Range  Required  (meaning  a  launch  could 
proceed  without  the  asset).  Available  Spare  (to  achieve  reliability  through  redundancy), 
or  User  Required/Mandatory.  User  Required/Mandatory  assets  are  not  necessary  for 
range  safety. 

Command  destruct  sites  at  Cape  Canaveral  are  generally  considered  launch 
mandatory.  Command  destruct  sites  at  Jonathan  Dickinson  Missile  Tracking  Annex 
(JDMTA)  are  usually  mandatory  since  there  are  times  that  the  JDMTA  sites  have  a  better 
look  angle. 

Telemetry  at  TEE  IV  (TAA-3c  and  TAA  50-3),  located  at  KSC,  is  required  for  the 
Space  Shuttle  and  mandatory  for  Delta  and  Atlas  launches.  JDMTA  is  required  for  East 
bound  launches.  The  launches  from  CCAES  or  KSC  generally  require  one  of  the  four 
JDMTA  telemetry  assets.  The  other  three  are  used  for  Navy  Submarine  Eaunched 
Ballistic  Missiles.  Space  Shuttle  launches  add  two  more  telemetry  sites  to  the  launch 
head  area,  one  on  Merritt  Island  and  the  other  at  Ponce  De  Eeon. 
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Optics  are  generally  required  for  all  range  launehes.  Many  assets  are  mobile,  so 
their  loeation  can  be  ehanged  depending  on  the  launeh  eomplex  used. 

Radar  is  eurrently  required  at  CCAFS/KSC/PAFB.  That  usually  ineludes  several 
Missile  Preeision  Instrumentation  Radars  (MIPIR,  whieh  uses  a  parabolie  reflector 
antenna)  and  a  phased  array  Multiple  Objeet  Traeking  Radar  (MOTR). 

All  eommand  destruet  sites  are  normally  part  of  the  range  eonfiguration.  Some 
discussions  of  the  AFTS  era  envision  it  in  full  use  around  2018.  That  may  be  a  reason  to 
keep  the  eommand  sites  on  a  separate  sub-net,  as  they  are  now.  They  generally  have  very 
striet  reliability  requirements,  whieh  may  be  another  reason  to  put  them  on  a  separate 
network.  On  the  other  hand,  they  have  a  redundaney  requirement,  and  a  no  single-point- 
of-failure  (SPOT)  requirement.  A  data  network  that  offers  multiple  routing  possibilities 
may  be  a  good  eoneept  to  meet  that  need.  The  ORD  (Headquarters  Air  Foree  Spaee 
Command,  DRSR,  2003)  does  not  speeify  redundaney  direetly,  but  does  say  in  Seetion 
4. 1.5.1  that  “The  ranges  must  be  capable  of  uplinking  commands  (i.e.  destruet,  arm,  safe, 
pilot  tones/eheek  ehannel  4  (WR),  or  control  fuel  burn)  from  launch  through  powered 
flight  or  separation  of  the  last  stage  designed  to  aceept  eommands.” 

a.  Conceptual  Architectures 

The  system  of  systems  coneepts  being  evaluated  are  likely  points  in  the 
range  evolution  toward  the  LET  plan  for  an  Eastern  Range  that  will  eompletely  use  GPS 
metrie  traeking  by  fiseal  year  2011  (Shappell,  2008).  A  depletion  of  the  EET  plan  is 
shown  in  Eigure  4.  The  strike-throughs  indieate  assets  that  are  deemed  no  longer 
required  when  GPS  metric  tracking  is  used  for  all  vehieles.  Divestiture  of  these  assets 
will  be  phased,  so  the  graphie  makes  a  distinetion  between  “New  Shutdowns”  (Radars 
19.17  and  1.16  plus  3  mobile  optieal  traekers),  and  Previous  “Shutdowns.” 
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LPLWS  =  Launch  Pad  Lightning  Warning  System 
CGLSS  =  Cloud  to  Ground  Lightning  Surveillance  Sys 
AMPS  =  Automated  Meteorological  Profiling  Sys 
SODAR  =  Sonic  Detection  &  Ranging  s 

OSS  =  Ocean  Surveillance  Sys 
DRWP  =  Doppler  Radar  Wind  Profiler 
MOTR=  Multiple  ObjectTracking  Radar 


=  Previously  ShutdoJjrt*'^ '' 


Figure  4.  Conceptual  View  of  Range  Architecture  (Slide  13,  Shappell,  2008) 


The  Eastern  Range  Capabilities  Documentation  chart  titled  “Typical 
Instrumentation  Configurations  for  Eastern  Range  Eaunch  Vehicles  and  Elight  Azimuths” 
shows  North  Easterly  launches  using  radars  at  Wallops  Island  and  Argentia  (Computer 
Sciences  Raytheon,  2008).  Given  the  current  trend,  this  thesis  assumes  telemetry  will  be 
used  instead.  The  radar  0.134  and  the  launch  head  optics  will  not  be  included  in  the 
range  safety  metric  track.  For  the  flight  profile  considered,  the  range  configuration 
(conceptual  architecture)  shown  in  Figure  5  would  likely  be  used. 


Figures.  Conceptual  Architecture 
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b.  Operational  Scenario 


The  operational  seenario  considered  in  this  thesis  is  a  North  Easterly 
Launch.  The  expectation  is  that  North  Easterly  launches  will  make  use  of  command  and 
telemetry  at  Wallops  Island  and  will  add  mobile  command  and  telemetry  assets  at 
Argentia.  JDMTA  typically  supports  North  Easterly  launches  with  two  telemetry 
antennas  and  command.  Currently  the  only  ER  GPS  processing  equipment,  the 
Translated  GPS  Receiver  System  (TGRS)  is  located  at  JDMTA.  The  range  allows 
customers  to  monitor  data  during  the  launch  and  access  recorded  data  after  the  launch. 
There  are  currently  no  provisions  for  customers  to  attach  their  own  instrumentation,  such 
as  telemetry  antennas,  or  optics  to  the  network  as  either  an  input  source  or  a  consumer  of 
designates  data. 

Any  operation  will  use  voice  and  video  to  monitor  status  and  for  command 
and  control.  The  Weather  and  Area  Surveillance  subsystems  will  also  contribute  to  the 
network  traffic.  These  loads  are  considered  as  a  steady  state  level  of  background  traffic. 
This  thesis  considers  Area  Surveillance  to  be  a  command  and  control  function  that 
primarily  uses  voice  and  video.  Weather  is  currently  connected  to  the  range  with  a  single 
OC-3  connection.  Eor  the  purposes  of  this  thesis,  it  is  assumed  that  the  required 
bandwidth  is  75%  of  the  available  OC-3  capacity  (Note:  each  OC-3  is  capable  of  carrying 
155  Mbps;  75%  equals  116  Mbps).  Similarly,  it  is  assumed  that  video  consumes  75%  of 
the  available  bandwidth  from  the  five  OC-3  lines  connecting  “TVOC”  to  the  core 
network  (NOTE:  five  OC-3  lines  are  capable  of  775  Mbps;  75%  equals  581  Mbps). 
Voice  is  generally  given  32  Kbps  circuits,  as  seen  in  the  CSR  Technical  Training 
Orientation  (Gillis,  2008).  Using  the  ERAT  estimate  of  600  voice  users  (ERAT,  2008, 
slide  1 1 1),  each  using  32Kbps  circuits,  requires  19.2  Mbps.  This  would  be  the  case  were 
it  not  for  the  ability  to  multiplex  the  voice  circuits.  One  T-1  line,  moving  Extended 
Superframes  at  1.544  Mbps,  can  handle  576  phone  calls  (Gillis,  2008).  Going  from  576 
to  600  by  linear  scaling  means  1.608  Mbps  are  used  for  voice. 
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In  the  modeling  of  the  proposed  modernized  network,  the  voice  and  video 
are  considered  to  be  a  constant  steady-state  level  that  shares  the  same  communication 
infrastructure  used  by  the  sensors.  The  level  of  activity  is  that  assumed  by  the  FRAT. 
The  FRAT  network  engineers  (Gorlick,  2008),  assuming  the  use  of  voice  compression 
software,  estimate  each  user  will  require  16  Kbps,  which  results  in  a  9.6  Mbps 
requirement  for  600  users.  For  the  video  use  of  bandwidth,  the  assumption  is  that  there 
will  be  150  live  feed  cameras  producing  1280  x  1024  pixel  images  (i.e.,  high  definition 
TV  quality)  at  a  rate  of  30  frames  per  second  using  real-time  compression.  The  resulting 
load  is  less  than  1  Gbps,  (FRAT,  2007,  slide  107),  so  the  video  load  is  assumed  to  be  999 
Mbps.  The  FRAT  does  not  explicitly  consider  the  network  loading  imposed  by  the 
Weather  and  Area  Surveillance  subsystems.  Again,  weather  is  considered  to  use  75%  of 
the  bandwidth  available  from  the  single  OC-3  connection  and  Area  Surveillance  is  part  of 
the  voice  and  video  load. 

c.  Range  Network 

In  this  thesis,  the  range  is  viewed  as  a  sensor  network  with  a  hub  and 
spokes  out  to  the  remote  sensors.  The  hub  includes  the  core  data  network.  Centralized 
Telemetry  Processing  System  (CTPS),  FOVl  and  the  command  destruct  control  system 
(Figure  6).  The  core  data  network  receives  a  lot  of  attention  in  the  FRAT  plan  (FRAT, 
2007),  since  this  part  of  the  network  needs  to  reliably  meet  strict  timeliness  requirements. 


Figure  6.  Hub  and  Spoke  Sensor  Network 
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d.  Alternative  1:  Legacy  Network  Model  Architecture 

A  review  of  the  Eastern  Range  Capabilities  Doeumentation  ehart,  “Typieal 
Instrumentation  Configurations  for  Eastern  Range  Eauneh  Vehieles  and  Elight 
Azimuths,”  shows  that  Wallops  Island,  JDMTA  and  the  Eauneh  Head  assets  will  all  be 
traeking  at  the  same  time.  The  times  the  missile  is  visible  from  JDMTA,  the  Eauneh 
Head,  Wallops  Island,  and  Argentia  are  shown  in  Table  4  (Computer  Seienees  Raytheon, 
2008).  The  network  model  in  this  thesis  considers  data  loads  from  Wallops  Island, 
JDMTA  and  the  Eauneh  Head  assets  simultaneously.  JDMTA  and  the  Eauneh  Head  will 
have  dropped  off  by  the  time  Argentia  can  track  the  missile. 


Table  4.  Time  Span  (in  seconds)  of  Missile  Visibility  from  Various  Sights 


JDMTA 

Launch  Head 

Wallops  Island 

Argentia 

Delta  II 

24-466 

0-482 

217-617 

504-890 

Atlas  V 

Not  listed 

0-483 

217-617 

549-793 

Shuttle 

49-450 

0-425 

196-683 

Not  listed 

This  model  architecture  uses  the  command  destruct  system  and  the  sensors 
left  by  the  EET  plan  after  the  range  begins  using  GPS  metric  tracking  for  all  launch 
vehicles.  The  metric  tracking  data,  both  GPS  and  IGS,  will  come  through  the  telemetry 
systems.  This  configuration  removes  the  radars  and  the  optics  from  the  range  safety 
solution,  so  there  will  be  no  data  flow  from  them,  but  they  will  receive  designate  data 
from  EOVl.  The  communications  infrastructure  will  be  the  equipment  currently  in  use. 
Early  in  the  launch,  the  assets  contributing  to  the  range  safety  solution  are  included 
among  those  seen  in  Eigure  7.  The  model  is  based  on  these  assets.  The  focus  is  the 
capability  of  the  network  to  meet  the  bandwidth  demands  and  meet  the  timeliness 
requirements. 
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e.  Alternative  2:  Modernized  Network  Model  Architecture 

This  model  architecture  uses  the  same  range  systems  as  alternative  1,  but 
the  data  network  will  use  IP  data  packets  rather  than  the  current  ATM  cells. 

2,  Identification  of  System  Threads 

This  thesis,  following  a  thread  from  the  OV-5  (Space  Lift  Range  System 
Contractor,  2007a)  focuses  on  the  range’s  ability  to  conduct  launch  operations.  Thread  3, 
“Execute  launch  and  test  range  operations,”  has  one  top-level  guard  condition  for 
reacting  to  a  non-nominal  flight  when  the  missile  violates  fight  safety  parameters.  It 
would  involve  a  decision  as  to  whether  or  not  to  destroy  the  rocket  or  otherwise  interrupt 
powered  flight. 

The  “Launch  and  Test  Range  Operations”  thread  is  decomposed  into: 

3.1.  Monitoring  heath  and  status  of  range  instrumentation 

3.2.  Monitor  space  and  launch  vehicle  preparation 

3.3.  Determine  launch  Go/No-Go  status 

3.4.  Manage  real-time  flight  operations 

3.5.  Track  objects 

3.6.  Perform  post  launch  activities 
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Thread  3.4,  “Manage  real-time  flight  operations,”  eovers  the  eontingeney  for  non- 
nominal  flights  that  ealls  for  sending  a  flight  termination  funetion. 

As  for  the  end  of  the  thread,  eonsideration  is  given  to  how  OV-5  deeomposes 
Item  3.4,  “Manage  real-time  flight  operations,”  shown  below.  Items  after  3.4.4. 1  are 
shown  in  italies.  The  timeliness  requirement  will  ehange  eonsiderably  after  all  the  debris 
traeking  is  eomplete.  For  that  reason.  Item  3.4.4. 1  will  be  the  end  point  of  the  thread. 

3.4.1.  Monitor  best  souree  metrie  data 

3. 4. 1.1.  Reeeive  and  send  raw  telemetry  data 

3. 4. 1.2.  Reeeive  and  send  radar  metrie  data 

3. 4. 1.3.  Distribute  time  eritieal  range  safety  telemetry  information 

3.4. 1.4.  Reeeive  best  souree  metrie  data 

3. 4. 1.5.  Monitor  and  seleet  sourees  to  ensure  aeeurate  display  of  metrie 
and  diserete  indieators 

3. 4. 1.6.  Seleet  and  transmit  best  souree  metrie  data 

3.4. 1.7.  Reeeive  best  souree  designate/aequisition  data 

3.4.2.  Confirm  Vehiele  performanee  with  respeet  to  predieted  vehiele 
performanee 

3.4.2. 1.  Deteet  missile  liftoff 

3.4. 2.2.  Reeeive  missile  liftoff  indieation 

3. 4. 2. 3.  Report  visual  vehiele  in-flight  behavior 

3. 4. 2.4.  Evaluate  vehiele  in-flight  telemetry  measurements 

3. 4. 2. 5.  Control  mission  flight  eontrol  display 

3. 4. 2. 6.  Monitor  airborne  range  safety  system  health  and  status 

3. 4. 2. 7.  Monitor  vehiele  performanee  with  respeet  to  predieted 
performanee 

3.4.3.  Terminate  non-nominal  vehiele  flight 

3.4.3. 1.  Deeide  to  terminate  non-nominal  flight  with  respeet  to  violations 
of  mission  rule  eriteria 
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3. 4. 3. 2.  Declare  vehicle  flight  non-nominal 

3. 4. 3. 3  Send  flight  termination  function 

3.4. 3.4.  Send  back-up  flight  Termination  Functions 

3. 4. 3. 5.  Transmit  termination  functions 

3. 4. 3. 6.  Verify  vehicle  destruction 

3.4.4.  Perform  debris  and  toxin  dispersion  analysis  based  on  catastrophic  abort 

3.4.4. 1.  Determine  debris  impact  area 

3. 4. 4. 2.  Generate  post-destruct  data 

3. 4. 4. 3  Receive  and  report  post  destruct  data 

3. 4. 4. 4.  Determine  refined  instantaneous  impact  point  data  and  debris 
impact  area 

3. 4. 4. 5.  Determine  updated  toxin  release  times  based  on  catastrophic 
abort 

3. 4. 4. 6.  Receive  and  report  updated  toxin  release  times 

3. 4. 4. 7.  Monitor  updated  toxin  release  times 

3. 4. 4. 8.  Release  assets  when  clearance  toxic  times  expire 

3.4.5.  Perform  mission  data  lockdown 

3. 4. 5.1.  Ensure  all  launch  related  records  and  data  is  secured 

3. 4. 5. 2.  Direct  data  control  and  disposition  actions 

3. 4. 5. 3.  Conduct  data  collection  and  disposition  actions 

3. 4. 5. 4.  Gather,  preserve  and  protect  evidence 

3.  Representation  of  Operational  Architectures  in  a  Unified  Modeling 
Language  (UML)-Like  Format 

This  step  corresponds  to  the  OV-6c  Diagram  of  the  Department  of  Defense 
Architecture  Framework  (DoDAF).  It  provides  an  examination  of  the  time-ordered 
exchange  of  information  between  the  scenario  actors.  This  view  (Figure  9)  helps  define 
the  interactions  making  up  the  operational  thread  and  can  help  ensure  each  actor  has  the 
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necessary  information  when  it  is  needed  to  perform  the  assigned  operational  activities. 
The  range  uses  a  hybrid  view  called  an  OV-6x.  This  analysis  will  draw  excerpts  from  the 
OV-6x  for  non-nominal  flights.  The  timing  requirements  in  this  view  are  driven  by  range 
safety  considerations. 

The  Missile  Flight  Control  Officer  (MFCO)  monitors  the  missile’s  flight  to 
determine  whether  it  is  violating  flight  safety  rules.  The  OV-6  will  focus  on  the  MFCO 
who  is  stationed  in  the  ROCC.  The  MFCO  is  part  of  a  team  that  includes  the  Range 
Control  Officer,  and  Flight  Safety  Officer,  as  well  as  assistants  to  monitor  the  command 
destruct  system  and  control  displays.  For  this  OV-6,  this  team  will  be  considered  a  single 
entity  referred  to  as  the  MFCO.  The  basic  information  flow  is  from  the  remote  sites  to 
FOVl,  where  it  is  processed  and  displayed  in  a  form  useful  to  the  MFCO.  FOVl  also 
sends  target  acquisition  data  (designate  data)  to  the  remote  sites.  The  MFCO  initiates  the 
destruction  sequence  if  deemed  necessary. 

The  telemetry  stream  carries  both  GPS  and  Inertial  Guidance  System  (IGS)  metric 
tracking  data.  IGS  data  is  transmitted  to  the  ROCC  where  it  is  processed  through  CTPS. 
CTPS  separates  the  data  and  outputs  X,  Y,  Z,  X',  Y',  Z',  time,  and  site  ID  to  FOVl. 
CTPS  also  processes  the  vehicle  health  and  status  information  for  display  to  the  MFCO. 
GPS  metric  tracking  data  processing  is  done  on  the  ground  at  the  JDMTA  telemetry  site 
by  a  system  called  the  Translated  GPS  Receiver  System  (TGRS).  TGRS  determines  the 
missiles  state  vector  and  sends  it  to  FOVl. 

Optics  and  radar  are  still  actors  in  the  launch  scenario  even  though  their  data  will 
not  be  used  to  determine  the  missile  state  vector.  Optics  will  supply  visual  data  to  the 
ROCC  throughout  the  operation.  Optics  and  radar  will  both  track  debris  and  they  will 
both  receive  designate  data  from  FOVl. 

The  event  sequence  (Figure  8)  does  not  change  as  the  missile  flies  down  range, 
but  the  timeliness  requirements  do.  For  the  launch  area,  the  timing  is  400  milliseconds 
for  a  sensor  to  get  the  data  frame  to  FOVl,  and  then  FOVl  has  100  milliseconds  to 
process  the  data  and  produce  a  display.  The  MFCO  needs  to  interpret  the  display, 
determine  that  a  vehicle  needs  to  be  destroyed  and  then  initiate  the  destruct  sequence. 
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The  time  allotted  to  the  MFCO  is  1500  milliseeonds.  The  eommand  destruet  system  then 
has  55  milliseconds  from  the  time  the  destruet  sequence  is  initiated  to  the  time  the 
leading  edge  of  the  pulse  carrying  the  command  function  leaves  the  antenna.  For  down 
range  sites,  the  sensors  have  1500  milliseconds  to  get  a  data  frame  to  FOVl,  and  the 
command  system  has  55  milliseconds  plus  the  data  link  latency  which  varies  depending 
on  the  specific  site  (Smith,  2008b)  to  start  sending  the  destruet  signal. 
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Figure  8.  Non-nominal  Launch  Event  Timing 
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Figure  9.  Representation  of  Operational  Scenario 
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Representation  of  Operational  Seenario  (eontinued) 
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Representation  of  Operational  Seenario  (eontinued) 
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Representation  of  Operational  Seenario  (eontinued) 
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4.  Identification  of  System  of  Systems  Design  Parameters  and  Factor 

Levels 

Network  system  performanee  is  driven  by  the  way  the  various  range  systems  are 
joined  to  ereate  the  system  of  systems.  A  popular  approaeh  is  the  use  of 
Publish/Subseribe  Middleware.  Quality  of  Serviee  measures  that  lend  themselves  to 
beeoming  design  parameters  for  this  analysis  are  1)  timeliness  2)  reliability  and  3) 
availability  (Corsaro,  Querzoni,  Seipioni,  Tueei  Piergiovanni,  &  Virgillito,  2006).  For 
this  applieation,  availability  addresses  sizing  the  network  to  ensure  data  ean  flow  to  the 
required  loeation  by  the  time  it  is  needed.  The  availability  parameter  is  evaluated  using  a 
throughput  analysis  and  does  not  eonsider  availability  in  the  sense  of  equipment  failure. 

a.  Timeliness 

The  prineipal  driver  for  sensor  data  timeliness  is  the  FOVl 
synehronization  seheme  that  groups  400-milliseoond  old  data  frames.  This  is  one 
element  in  an  overall  range  timeliness  requirement.  The  overall  range  timeliness 
requirement  is  driven  by  the  need  to  proteet  the  publie  from  the  hazards  potentially 
resulting  from  a  missile  that  violates  flight  safety  rules. 

b.  Reliability 

In  the  legaey  network  eonfiguration,  reliability  is  addressed  by  requiring 
two  independent  paths  for  range  safety  eritieal  data  for  reliably  through  redundaney.  For 
the  parts  of  the  range  network  that  eonsist  of  leased  eommereial  lines,  the  reliability 
guaranties  need  to  be  eonsidered  beeause  how  the  reliability  is  aehieved  is  beyond  the 
range’s  eontrol.  Deeisions  to  migrate  to  a  new  range  network  eonfiguration  will  need  to 
eonsider  network  reliability  and  examine  the  fault  toleranee  and  robustness  of  the 
network.  Simply  mandating  two  paths  may  not  be  the  best  solution.  Other  network 
topologies  with  the  ability  to  route  traffie  to  meet  the  QoS  requirements  might  prove  to 
be  the  best  solution.  Corsaro  et  al  (2006)  suggest  that  faetors  affeeting  reliability  inelude 
persistenee  of  events  and  event  retransmission.  In  eonsidering  a  move  toward  an  IP- 
based  network,  one  might  eonsider  if  there  is  time  or  a  need  to  resend  lost  paekets.  This 
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may  not  be  necessary  since  data  packets  are  set  every  100  milliseconds.  Additionally, 
FOV 1  is  tolerant  of  an  occasional  missed  data  frame.  This,  combined  with  data  latency 
limitation,  makes  retransmission  unnecessary. 

Corsaro  et  al  (2006)  also  discuss  a  “lifespan”  parameter  that  allows  control 
over  the  time  interval  for  which  the  data  will  be  valid.  The  lifespan  of  the  data  is  set  by 
FOVl.  Radar  and  optics  data  frames  up  to  one  second  old  will  be  processed  whereas 
telemetry  borne  data  (IGS  and  GPS)  up  to  1.2  seconds  is  allowable,  although  a  400- 
millisecond  time  span  for  all  data  is  desirable.  The  current  FOVl  configuration  is  set  up 
to  synchronize  inputs  so  that  all  400  millisecond  old  data  frames  are  processed  at  the 
same  time.  If  the  data  is  not  used  in  that  time,  it  should  not  remain  in  the  network. 
Additionally,  there  is  no  reason  to  check  receipt  of  a  data  frame  and  communicate  it  back 
to  the  provider,  because  messages  are  created  and  sent  rapidly  (10  per  second).  If  an 
expected  data  frame  fails  to  arrive  on  time,  FOVl  will  compute  the  solution  using 
available  data. 


c.  Availability 

Ensuring  data  arrives  where  it  is  needed  in  the  allotted  time  is  dependent 
on  having  enough  bandwidth.  There  are  two  basic  types  of  data  used  during  launch 
operations:  range  safety  data  and  customer  data.  The  range  safety  data  is  necessary  to 
determine  a  state  vector  for  the  missile  and  for  monitoring  health  and  status  of  the 
command  receiver.  The  customer  data  can  be  subdivided  into  two  groups:  the  data  that 
need  be  processed  in  real  time  and  the  data  that  can  be  recorded  and  processed  after  the 
mission.  Basic  vehicle  health  and  status  data  is  sent  real  time.  There  is  a  dividing  line 
between  the  data  that  can  wait  based  on  customer  wants.  In  some  cases,  the  entire 
telemetry  stream  needs  to  be  sent  to  the  ROCC,  since  the  safety  data  may  not  be  put  on  a 
dedicated  channel. 

Ideally,  one  would  not  have  to  wait  for  data,  but  certain  data,  such  as 
engineering  analysis  optics  data,  would  require  huge  amounts  of  bandwidth.  Since 
analysis  can  be  done  after  the  launch,  the  data  can  be  stored  and  transmitted  later.  Radar 
imaging  or  tracks  made  with  very  high  sample  rates  could  potentially  create  large 
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amounts  of  data  that  could  be  used  for  later  analysis  of  debris  metries  and  diserimination. 
Clearly  some  data  needs  extensive  analysis  that  eannot  be  done  in  the  time  span  of  a 
launeh  operation,  so  transporting  it  ean  happen  after  the  operation. 

With  a  view  of  the  range  as  a  sensor  network,  the  throughput  requirements 
for  the  legaey  sensors  are  very  small.  Radar  and  opties  are  designed  for  a  2.4-Kbps  data 
stream,  and  Telemetry  is  set  up  for  a  4.8-Kbps  data  steam.  These  rates  are  aetually  a 
bigger  problem  for  timeliness  than  for  throughput,  beeause  it  takes  a  signilieant  amount 
of  time  to  build  a  data  frame.  A  240-bit  frame  built  at  2.4-Kbps  and  4.8-Kbps  rates  takes, 
respeetively  100  and  50  milliseeonds  to  eomplete.  Additionally,  there  is  a  60  milliseeond 
delay  when  transporting  these  sub-rate  data  frames  onto  the  range  network  (Gillis,  2008). 

The  telemetry  eapaeity  requirement  needs  to  be  evaluated  as  new  Spaeelift 
vehieles  are  developed.  The  Telemetry  Subsystem  Speeifieation  is  ealling  for  10  Mbps. 
Early  indieations  are  that  the  NASA  Aries  program  will  have  telemetry  streams  as  large 
as  30  Mbps.  One  approaeh  to  handling  this  load  is  for  the  telemetry  stream  to  have  a 
spare  ehannel  to  allow  a  small  portion  of  the  stream  to  be  separated  for  use  for  range 
safety  data,  and  the  rest  reeorded.  Another  approaeh  may  be  to  have  an  IP -based 
telemetry  signal  that  the  site  proeesses  at  the  routing  level  (Gorliek,  2008). 

5.  Transformation  of  UML-like  Format  Representation  into  Executable 

Models 

The  design  parameters  eonsist  of  availability  (throughput)  and  timeliness. 

a.  Availability 

The  availability  model  analyzes  required  data  flow  by  foeusing  on  the 
nodes  eonneeting  remote  site  data  links  to  the  eore  data  network.  The  model  sums  the 
volume  of  data  that  flows  in  and  out  of  the  eore  network  through  various  nodes  and 
eompares  the  result  to  the  rated  eapaeity  of  622  Mbps.  Similarly,  the  individual 
throughputs  are  summed  and  eompared  to  the  node  throughput  eapaeity  of  2088  Mbps. 
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The  core  has  eight  switches  on  the  outer  ring  and  seven  on  the  inner  ring. 
This  analysis  models  the  core  as  six  switches  with  four  on  the  outer  ring  and  two  on  the 
inner  ring  (Figure  10).  The  primary  focus  is  on  the  range  safety  information  and  the  need 
to  process  it  at  the  ROCC  and  present  it  for  consideration  to  the  MFCO.  In  addition  to 
the  flow  of  range  safety  data  to  FOVl,  and  the  target  acquisition  data  going  back  to  the 
remote  sites,  the  analysis  assumes  steady  state  network  traffic  that  includes  video,  voice, 
and  weather. 


Figure  10.  Model  Representation  of  Range  Network 


With  a  focus  on  getting  sensor  information  to  FOVl/DRSD,  the  paths 
being  modeled  are  1)  Telemetry  data  to  get  on  the  core  for  transport  to  CTPS,  then  to 
FOVl,  and  2)  Telemetry  data  to  get  on  the  core  for  transport  to  TORS,  then  to  FOVl 
(Figure  11). 
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Remote  site  Core  ROCC  CTPS  FO\’l  DRSD 


State  \'ector.  Health  and  Status 

- ► 

, Designate  Data 


Remote  site  Core  TGRS  ROCC  FO\'l  I^SD 


State  \'ector ^ 

^ Designate  Data 
Figure  1 1 .  Basic  Data  Flow  Model 

During  a  launch  operation,  the  circuits,  or  data  paths,  are  predetermined. 
The  only  variation  comes  from  routing  on  the  core.  The  core  rings  are  designed  to  be 
fault  tolerant  in  that  they  react  to  a  node  failure  by  routing  the  network  traffic  around  the 
ring  in  the  opposite  direction.  The  only  capability  lost  is  the  ability  to  add  or  remove  data 
from  the  core  via  the  failed  node.  The  input  and  output  nodes  for  the  circuits  stay  static. 
The  reliability  issue  is  addressed  by  setting  up  redundant  paths  that  carry  the  same  data. 
The  basic  node-by-node  analysis  of  throughput  is  done  for  the  current  network  and  for 
the  FRAT  proposed  network  that  is  based  on  IP  packets.  The  current  network  uses  ATM 
cells.  The  type  of  data  flowing  on  the  network  will  be  the  same,  but  the  volume  will 
differ  slightly.  The  node  model  used  is  shown  as  Figure  12. 
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Core  Node  for  subsystem 
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Through  puts 
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Outputs 


Input 
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10 
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10 
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20 

Capacity 
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_ 

Through  put 

Rate  (MBPS) 

Through  puts 

1000 
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1000 

Capacity 
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Figure  12.  Basic  Flow  Model 


The  sum  of  the  inputs  and  outputs  is  compared  to  the  capacity  of  the  data 
link  connecting  to  the  node  to  determine  if  the  link  has  the  required  bandwidth. 

b.  Timeliness 


The  timeliness  model  analyzes  the  latency  of  the  data  flow  from  remote 
sensors  to  FOVl.  The  focus  is  on  the  network —  both  the  legacy  and  FRAT  proposed 
network.  The  analysis  is  done  by  summing  the  data  latency  caused  by  the  various 
processes  performed  to  create  the  data  links.  The  data  link  latency  is  added  to  the  TGRS 
or  CTPS  processing  time  and  compared  to  the  400  millisecond  allocated  for  getting  data 
to  FOVl.  The  CTPS  processing  time  is  assumed  to  be  the  difference  in  the  time  budgets 
for  telemetry  and  radar,  which  is  an  extra  200  milliseconds.  The  TGRS  processing  time 
is  assumed  to  be  the  same  as  CTPSs. 

The  difference  in  data  latencies  is  most  pronounced  at  the  edge  devices 
that  transition  data  on  or  off  the  core  network.  The  data  latency  in  the  legacy  network 
caused  by  the  edge  devices  is  tabulated  in  Table  5  (Morton,  2008). 

Table  5. 
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Table  6.  Edge  Deviee  Delay  Times  from  Interfacing  with  Various  Circuit  Types 


OC-48  transitioned  to/from 

Delay 

(milliseconds) 

Low  speed  synchronous  serial  (2.4  Kbps) 

60 

Individual  DSO  (56  Kbps)  channel  in  DS-1 

37 

DS-1  circuit 

3 

An  IP  packet-based  network  will  also  introduce  a  data  latency  at  the  edge 
devices.  The  latency  is  estimated  to  be  5-10  milliseconds  (Bryant,  2008).  Since  the 
legacy  network  meets  the  latency  requirements  and  since  the  proposed  IP  network  is 
faster,  the  IP  network  will  meet  the  need. 

Review  of  the  data  link  latency  of  a  range  configured  to  use  GPS  metric 
tracking  for  range  safety  now  follows.  The  timeliness  analysis  focuses  on  the  circuit  path 
that  is  the  worst  case  in  terms  of  time  budgets.  The  tightest  time  requirement  is  for  the 
launch  head  sensors.  They  have  to  have  data  to  FOVl  in  no  more  than  400  milliseconds. 
TEL  IV  (telemetry)  will  be  the  only  launch  head  sensors  left  after  the  range  begins  using 
GPS  metric  tracking  for  all  launches.  The  analysis  focuses  on  the  data  links  that  take 
TEL  IV  (launch  head)  data  to  JDMTA  (down  range)  to  be  processed  through  TGRS  and 
then  carries  the  TGRS  computed  state  vector  to  FOVl. 

TEL  IV  data  is  routed  through  the  XY  building  as  it  is  transmitted  to 
JDMTA.  The  time  needed  to  get  data  from  TEL  IV  to  the  XY  building  is  5  milliseconds. 
This  value  is  based  on  a  measured  time  of  10  milliseconds  for  telemetry  data  to  pass  from 
the  TEL  IV  WANIU  through  the  CTPS  WANIU  (Space  Lift  Range  System  Contractor, 
2004).  Because  the  latency  for  traveling  along  the  fiber  optic  data  link  is  negligible,  this 
analysis  assumes  a  10-millisecond  latency  is  attributable  to  processing  by  two  WANIUs, 
each  taking  5  milliseconds.  This  assumption  is  used  for  both  the  microwave  path  and  the 
landline  path.  Data  also  has  both  a  microwave  path  and  a  landline  path  from  the  XY 
building  to  JDMTA. 
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The  landline  trip  from  the  XY  building  to  JDMTA  begins  at  switeh 
XY_RNE_U15  and  travels  via  commereially  leased  lines  consisting  of  a  56-KB 
multiplexed  data  lines,  four  T-1  lines,  and  two  64-KB  control  lines  (Computer  Sciences 
Raytheon,  2008).  The  data  latency  of  the  leased  lines  is  estimated  because  the  exact 
routing  is  not  known.  To  estimate  the  data  latency,  this  analysis  assumes  the  data  is 
aggregated  on  to  an  OC-48  line  for  a  section  of  the  trip,  but  the  section  is  too  short  to 
realize  any  advantage  over  using  the  T-1  lines.  The  result  is  added  latency  for  the 
conversion  process.  Additionally,  the  analysis  assumes  that  the  path  length  is  twice  the 
shortest  route  distance.  The  trip  from  switch  XY_RNE_U126  to  JDMTA  and  back  will 
be  modeled  as  shown  in  Eigure  13. 

LcMcdLandlln*  Trip  to  JDMTA 


Eigure  13.  Eandline  Path  Model 


Analyzing  the  microwave  path  begins  with  the  assumption  that  the  data 
that  travels  from  TEE  IV  via  microwave  to  the  XY  building  will  stay  on  the  microwave 
path  and  will  be  relayed  to  JDMTA.  The  alternative  is  to  put  the  TEE  IV  data  onto  the 
core  through  the  OC-48  fiber  from  switches  XY  RNE  UI 13  to  XY_RNE_UI26.  Doing 
so  would  involve  processing  the  data  through  the  SONET  multiplexer  to  put  the  data  on 
the  core,  and  back  through  another  SONET  multiplexer  to  get  back  on  the  microwave 
link. 

The  microwave  path  from  TEE  IV  to  JDMTA  goes  through  5  repeater 
stations  and  travel  1 18.2  miles.  When  the  data  gets  to  JDMTA  it  goes  through  a  WANIU 
before  it  is  processed  by  TORS.  On  the  return  trip,  the  TORS  output  data  is  multiplexed 

47 


and  aggregated  into  a  5  3 -Byte  data  frame  that  ean  be  put  onto  the  network,  which  will 
take  approximately  25  milliseconds.  Figure  14  illustrates  this  path.  The  processing  time 
used  in  this  analysis  for  multiplexing  and  de-multiplexing  is  derived  from  latency 
measurements  for  telemetry  data  coming  from  the  remote  sites.  The  measurements  were 
reported  in  a  characterization  of  the  Post-Detect  Telemetry  Subsystem  WANIU  (Space 
Lift  Range  System  Contractor,  2004).  The  measurement  is  taken  from  the  time  data 
entered  the  WANIU  at  the  remote  site  until  it  is  processed  through  the  WANIU  that  feeds 
into  CTPS.  To  determine  the  time  attributable  to  multiplexing  and  de-multiplexing,  the 
portion  of  that  time  attributable  to  data  traveling  the  physical  distance  from  remote  site  to 
the  ROCC  is  subtracted  from  the  measured  time.  The  resulting  time  is  divided  by  two 
since  there  is  a  WANIU  at  both  ends.  After  the  return  trip  via  the  microwave  system,  the 
data  goes  through  another  Alcatel  radio  and  is  multiplexed  in  order  to  input  into  switch 
XY_RNE_126. 

Microwave  path 

De-mux 

_ _ 


TGRS 


I 

Muk 


Figure  14.  Microwave  Path  Model 

The  delay  from  converting  the  data  to  an  analog  radio  transmission  is 
assumed  to  be  the  same  as  the  repeater  time  delay  since  both  operations  are  processed 
through  an  Alcatel  4308S  radio.  Some  insight  into  the  time  delay  comes  from  a  study 
(Allen,  1994)  that  characterizes  the  delay  in  the  repeaters  used  in  an  Alcatel  Network 
Systems  microwave  network.  The  study  reports  the  worst-case  delay  of  577 
microseconds. 
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The  time  required  for  TGRS  data  to  reaeh  the  eore  is  the  same  as  the  time 
neeessary  to  reaeh  FOVl  beeause  the  core  is  so  fast  that  the  latency  from  the  XY  building 
to  FOVl  is  negligible  (Morton,  2008).  Therefore,  the  total  latency  for  getting  a  GPS  state 
vector  from  telemetry  data  collected  at  TEL  IV  data  is  the  sum  of  the  time  needed  to  get 
telemetry  data  from  TEL  IV  to  the  XY  building,  the  time  to  get  the  data  to  JDMTA  and 
back,  and  the  TGRS  processing  time. 

c.  Timelines:  Backward  Compatibility 

The  effect  of  making  modern  sensors  adhere  to  the  legacy 
communications  standards  is  evaluated  by  considering  the  range  radar  re-capitalization 
projects.  Legacy  radar  produces  data  in  240-bit  frames.  The  re-capitalized  radars  using 
MIT-LL  ROSA  are  required  to  produce  such  data,  however  the  240-bit  data  frame  is  not 
amenable  to  transport  on  the  data  network,  which  transfers  T-1  size  data  frames.  The 
process  time  for  converting  240-bit  data  frames  to  T-1  frames  is  60  milliseconds 
(Computer  Sciences  Raytheon,  2008).  In  addition  to  the  60-millisecond  conversion 
latency,  there  is  an  additional  100  milliseconds  needed  to  receive  the  240  bit  data  frame 
at  the  2.4-Kbps  rate  resulting  in  160  milliseconds  for  the  conversion  process.  This 
latency  and  the  system  complexity  that  come  with  this  conversion  could  have  been 
avoided  because  the  ROSA  data  is  readily  available  in  the  T-1  format.  The  requirement 
for  the  new  radars  to  output  a  legacy  format  should  be  changed  so  the  output  is 
compatible  with  the  data  network. 

6,  Application  of  Design  of  Experiments 

This  thesis  compares  two  architectures  rather  than  comparing  a  variety  of 
solutions  that  were  generated  by  varying  several  parameters.  This  course  of  action  was 
shaped  by  a  Headquarters  Air  Lorce  Space  Command  (AFSPC)  decision  regarding  the 
evolution  of  the  range.  This  thesis  is  concerned  with  evaluating  the  range  readiness  to 
achieve  the  ALSPC  commander’s  vision  and  considers  the  feasibility  of  adopting  the 
PRAT.  The  problem  is  bounded  by  considering  only  the  minimum  and  maximum  data 
load  on  the  range  network.  The  minimum  load  is  associated  with  the  currently  network 
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and  the  maximum  load  would  correspond  to  the  FRAT  plan  network.  Design  of 
experiments  is  not  used  since  only  two  configurations  are  considered. 

7.  Modeling  and  Analysis  of  Results 

Two  models  are  used,  one  to  assess  availability  and  the  other  to  evaluate 
timeliness.  The  availability  model  analyzes  required  data  flow  by  summing  the  volume 
of  data  that  flows  in  and  out  of  the  core  network  through  various  nodes  and  compares  the 
result  to  the  rated  capacity  of  622  Mbps.  Similarly,  the  individual  throughputs  are 
summed  and  compared  to  the  node  throughput  capacity  of  2088  Mbps.  The  timeliness 
model  analyzes  the  latency  of  the  data  flow  from  remote  sensors  to  FOVl.  The  focus  is 
on  the  network —  both  the  legacy  and  FRAT  proposed  network.  The  analysis  is  done  by 
summing  the  data  latency  caused  by  the  various  processes  performed  to  create  the  data 
links. 

A  large  set  of  the  data  that  flows  through  the  network  is  modeled  as  steady-state 
network  traffic,  consisting  of  video,  voice,  and  weather  data.  Additional  throughput 
includes  20  Mbps  of  telemetry  data  (10  Mbps  on  both  the  primary  and  secondary  paths) 
from  each  of  three  sites,  two  sets  of  TGRS  data,  and  two  sets  of  designated  data  returning 
to  the  remote  sites.  The  node  throughput  analysis  is  summarized  in  Table  6. 
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Table  7.  Network  Traffie  that  Passes  Through  the  Network  Nodes 


Legacy  Network  (Mbps) 

FRAT  IP  Based  Network  (Mbps) 

Video 

581 

999 

Voice 

1.608 

9.6 

Weather 

116 

116 

Telemetry 

60 

60 

TGRS 

0.074 

0.082 

Target  Acquisition  Data 

0.008 

0.010 

SUM 

758.7 

1184.6 

Capacity 

2088 

2088 

%  Used 

36 

57 

One  major  differenee  between  the  legaey  network  and  the  FRAT  proposed 
network  is  that  the  FRAT  plan  ealls  for  using  high  definition  quality  video  and  voiee  over 
IP.  Another  differenee  is  that  the  legaey  network  uses  5 3 -Byte  eells  eompared  to  the  64- 
Byte  IP  paekets.  This  differenee  will  have  a  small  impaet  on  the  bandwidth  eonsumed  by 
the  legaey  data.  In  order  to  reduee  lateney,  low  rate  data  frames  are  put  in  eells  (or 
paekets)  that  are  sent  before  they  are  full,  beeause  it  takes  too  long  to  fill  the  eells  with 
the  low  rate  input.  In  the  eurrent  range  network,  424-bit  eells  are  sent  with  the  legaey 
240-bit  frame  and  184  filler  bits,  whieh  use  1.77  times  more  bandwidth  than  eells 
eompletely  filled  with  data.  Similarly,  a  64-Byte  paeket  eonsumes  2.13  times  more 
bandwidth.  This  bandwidth  penalty  is  applied  to  the  legaey  data  eoming  from  TGRS  and 
CTPS,  as  well  as  the  Health/Status  data  and  the  designated  data.  A  eomparison  of  the 
bandwidth  eonsumed  under  different  data  strueturing  options  is  summarized  in  Table  7. 
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Table  8.  Comparison  of  Bandwidth  Consumed  Under  Different  Data  Structures 


Raw  Data  (Mbps) 

Data  in  Cells  (Mbps) 

Data  in  IP  Packets 

(Mbps) 

TGRS 

0.019 

0.034 

0.041 

CTPS 

0.014 

0.025 

0.029 

Health/Status 

0.064 

0.113 

0.136 

Note  that  the  terms  input  and  output  are  from  the  point  of  view  of  the  core.  When 
a  process  needs  data,  it  is  an  output  from  the  core.  The  results  from  running  the  process 
are  inputs  to  the  core.  For  example,  processing  TRGS  at  JDMTA  requires  that  the  TEL 
IV  and  Wallops  telemetry  streams  be  taken  as  output  from  the  network  core.  JDMTA 
will  process  data  with  TORS  and  input  the  data  on  to  the  core.  JDMTA  will  also  input  its 
own  telemetry  stream  so  it  can  be  processed  at  TEL  IV  and  by  CTPS. 

a.  Availability 

The  nodes  that  bring  Telemetry  data  to  CTPS  are  the  ATM  switches 
designated  as  ROCC_GNE_U110,  which  handles  CTPS  A,  and  ROCC_RNE_Ul  1 1, 
which  handles  CTPS  B.  The  throughput  model  for  ROCC  GNE  Ul  10  is  shown  in 
Eigure  15  below.  The  results  for  all  the  nodes  are  summarized  in  Table  8. 
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Core  Node  for  CTPS 


Video 

Vioce 

Weather 


CTPS  A 
Health/Status 


>  ROCC 

>  GNE 
UllO 


> 

■> 

■> 

> 

■> 

■> 

> 


TM-JDMTAA 
TM-JDMTAC 
TM-Tel  IV  A 
TM-Wallops  A 
CRTS  A 
Health/Status 
TGRS  A 


Legacy  Network 

Input 

Rate  (Mbps) 

CTPS  A 

0.027 

Health/Status 

0.113 

Output 

TM-JDMTAA 

10 

TM-JDMTAC 

10 

TM-Tel  IV  A 

10 

TM-Wallops  A 

10 

CRTS  A 

0.027 

Health/Status 

0.113 

TGRS  A 

0.111 

Total 

40.391 

Capacity 

622 

%  Used 

_ 

FRAT  IP  Based  Network 

Input 

Rate  (Mbps) 

CTPS  A 

0.03 

Health/Status 

0.136 

Output 

TM-JDMTAA 

10 

TM-JDMTA  C 

10 

TM-Tel  IV  A 

10 

TM-Wallops  A 

10 

CRTS  A 

0.03 

Health/Status 

0.136 

TGRS  A 

0.123 

Total 

40.455 

Capacity 

622 

%  Used 

_ 6*5. 

Figure  15.  Core  Node  Conneeted  to  CTPS 


Another  important  set  of  nodes  for  range  safety  are  the  nodes  that  send 
Telemetry  data  to  JDMTA  where  it  is  proeessed  through  TGRS.  JDMTA  is  eonneeted  to 
the  XY  building  by  commereial  eommunieation  links  and  by  an  Aleatel  mierowave  radio 
system.  The  mierowave  link  has  the  eapaeity  of  an  OC-3  line  and  the  eommereial  link 
uses  four  T-1  lines  (Space  Lift  Range  System  Contractor,  2007).  All  JDMTA  data  comes 
through  a  single  Cellworx®  switch  designated  as  XY_RNE_U126.  The  range  generally 
uses  redundant  data  links  but  this  switch  is  a  single  point  of  failure  because  both  links  use 
the  switch.  If  this  single  point  of  failure  is  a  problem,  a  potential  solution  is  to  switch 
microwave  receiver  connections  between  JDMTA  and  TEL  IV,  which  is  connected  to 
switch  XY_RNE_U1 13,  also  in  the  XY  building. 
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The  connection  between  the  core  and  JDMTA  needs  further  consideration. 
The  commercial  link,  using  four  T-1  lines,  is  only  capable  of  carrying  6.176  Mbps.  If 
entire  telemetry  streams  do  need  to  be  sent  for  TGRS  processing,  the  requirement  would 
be  40  Mbps.  Either  the  volume  of  telemetry  data  needs  to  be  reduced  or  the  link  capacity 
increased. 

After  the  data  is  processed  through  CPTS  and  TGRS,  it  needs  to  be 
processed  by  FOVl  and  DRSD  and  displayed  for  the  MFCO.  FOVl  B  and  DRSD  can 
receive  inputs  through  switches  ROCC_RNE  U102  and  ROCC_RNE_U  1 1 1 .  FOVl  A 
receives  its  data  from  ROCC  GNE  FllOlandROCC  RNE  FlllO. 


Table  9.  Network  Traffic  Put  On  or  Removed  from  the  Core  Through  Various  Nodes 
(Note  that  the  capacity  to  add  and  remove  data  is  622  Mbps) 


Legacy 

FRAT  IP  Based 

Total 

%  Used 

Total 

%  Used 

ROCC_GNE_U110 

40.32 

6.5 

40.38 

6.5 

ROCC_RNE_Ulll 

40.32 

6.5 

40.38 

6.5 

XY_RNE_126 

80.07 

12.9 

80.07 

12.9 

XY_RNE_113 

40.07 

6.4 

40.09 

6.4 

ROCC_GNE_U101 

0.238 

0 

0.262 

0 

ROCC_RNE_U102 

0.238 

0 

0.262 

0 

b.  Timeliness 

The  commercial  landline  model  sums  the  time  required  for  each  leg  of  the 
path  from  the  XY  building  until  the  TGRS  data  is  put  on  the  core  through  switch 
XY_RNE_U126.  The  results  are  shown  in  Figure  16. 
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Leased  Landline  Trip  to  JDMTA 


Element 

Delay  (msec) 

Convert  to  T-1 

3 

Travel  118.2  miles 

0.63 

Convert  to  OC-48 

3 

Convert  to  T-1 

3 

Travel  118.2  miles 

0.63 

Multiplex 

24.7 

Travel  118.2  miles 

0.63 

Convert  to  OC-48 

3 

Convert  to  T-1 

3 

Travel  118.2  miles 

0.63 

Convert  to  OC-48 

3 

Total 

45.22 

Figure  16.  Data  Timeliness  Model  Using  Commereial  Landlines  from  JDMTA  to  the 

Core  Network 


The  total  data  lateney  is  determined  by  adding  the  latency  for  data  travel 
from  TEL  IV  to  the  core,  the  TORS  processing  time,  and  the  time  needed  to  get  data  to 
JDMTA  and  back.  The  result  is  an  overall  time  of  250  milliseconds,  which  is  within  the 
400-millisecond  time  budget. 

The  microwave  link  model  sums  the  time  required  for  each  leg  of  the  path 
from  the  XY  building  until  the  TORS  data  is  put  on  the  core  through  switch 
XY_RNE_U126.  The  results  are  shown  in  Eigure  17. 
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Microwave  path 


Element 

Delay  (msec) 

Alecatel  Radio 

0.58 

5  Repeaters 

2.89 

Travel  118.2  miles 

0.63 

Alecatel  Radio 

0.58 

De-multiplex 

24.7 

Muxiplex  (plus  framing) 

24.7 

Alecatel  Radio 

0.58 

5  Repeaters 

2.89 

Travel  118.2  miles 

0.63 

Alecatel  Radio 

0.58 

De-multiplex  (to  DS-1) 

3 

Total 

61.74 

Figure  17.  Data  Timeliness  Model  Using  the  Mierowave  Radio  System  from  JDMTA 

to  the  Core  Network 


The  total  data  latency  is  determined  to  be  267  milliseconds,  which 
accounts  for  traveling  from  TEL  IV  to  the  core  network,  the  TORS  processing  time,  and 
the  time  needed  for  data  to  travel  to  JDMTA  and  back.  This  latency  is  within  the  400- 
millisecond  time  budget. 


C.  RESULTS 


Regarding  the  availability  requirements,  the  total  load  on  the  data  network  is 
estimated  to  be  36%  of  the  capacity  using  the  legacy  systems  and  57%  if  various 
modernized  systems  (e.g.  voice  over  IP,  IP  based  video)  are  used.  Range  safety  data  is 
less  than  8%  of  the  total  load.  As  for  the  ability  to  add  and  remove  data  from  the  core, 
range  safety  uses  at  most  13%  of  the  available  capacity,  which  is  driven  by  large  volumes 
of  telemetry  data. 
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The  commercial  leased  lines  to  JDMTA  are  a  potential  area  for  a  data  bottleneck. 
The  data  link,  using  four  T-1  lines,  is  capable  of  carrying  6.176  Mbps.  The  capacity 
required  to  send  all  the  telemetry  data  is  40  Mbps.  The  problem  of  the  bandwidth 
demand  exceeding  the  available  capacity  can  be  addressed  by  either  increasing  capacity, 
or  decreasing  demand.  The  demand  can  be  decreased  if  the  portion  of  the  telemetry 
stream  carrying  the  GPS  data  can  be  separated  so  that  only  a  subset  of  the  data  is  sent  to 
JDMTA.  If  the  GPS  data  were  carried  on  a  separate  telemetry  channel,  the  required 
capacity  would  likely  be  close  to  40  Kbps. 

With  regard  to  timeliness,  sending  telemetry  data  from  TEL  IV  down  range  to 
JDMTA  so  it  can  be  processed  through  TGRS  is  the  most  challenging  because  TEL  IV 
must  meet  the  timeliness  requirements  of  a  launch  head  sensor.  The  data  latency  of  the 
GPS  state  vectors  received  by  TEL  IV  is  estimated  to  be  250  milliseconds  for  the  landline 
data  link  and  267  milliseconds  using  the  microwave  system.  The  launch  head  timeliness 
requirement  of  400  milliseconds  is  thus  met. 

The  backward  compatibility  requirement  needs  to  be  viewed  from  a  network 
perspective.  Interfaces  are  currently  defined  by  the  legacy  serial  data  format  rather  than 
by  the  actual  communications  network.  Addressing  these  legacy  interface  requirements 
was  done  at  the  project  level  by  the  radar  team,  rather  than  with  a  re-look  at  the  range 
system,  resulting  in  an  extra  260  milliseconds  of  data  latency.  With  the  growing 
dependence  on  telemetry,  and  the  importance  of  data  timeliness,  the  interfaces  need  to  be 
considered  carefully. 

D.  SUMMARY 

This  thesis  takes  the  range  as  a  weapon  system  point-of-view  and  focuses  on  data 
availability  and  timeliness  to  meet  the  range  safety  requirements,  which  are  derived  from 
the  basic  need  to  protect  the  public  and  range  personnel.  The  range  is  also  required  to 
perform  many  Automated  Information  Systems  functions  which  demand  far  more 
bandwidth  than  the  range  safety  functions,  whose  timeliness  is  less  critical. 
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From  a  network  perspective  there  is  ample  bandwidth  to  meet  the  range 
requirements.  Moving  to  an  IPv6  based  network  will  not  have  a  significant  impact  on  the 
available  bandwidth,  assuming  the  existing  cables  and  fibers  are  used.  The  most 
significant  bandwidth  limitation  is  the  commercially  leased  data  link  from  the  core  to 
JDMTA.  The  link  cannot  carry  the  entire  stream  of  telemetry  data,  so  the  portion 
carrying  the  GPS  data  needs  to  be  separated.  After  the  change  to  using  GPS  for  all 
vehicles,  data  timeliness  requirements  can  be  met  with  the  current  network  or  an  IPv6 
based  network.  Data  timeliness  needs  to  be  considered  carefully  in  so  far  as  it  is  affected 
by  the  location  of  the  TGRS.  Additionally,  there  exists  the  potential  to  improve 
timeliness  by  examining  the  need  to  maintain  legacy  communication  standards. 
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IV.  CONCLUSIONS  AND  RECOMMENDATIONS 


A,  CONCLUSIONS 

Answering  research  question  1  (Question  1 :  Should  the  Spacelift  Ranges  migrate 
their  data  networks  to  an  IPv6  standard  as  proposed  by  the  Future  Range  Architecture 
Team?):  Both  the  current  range  network  and  an  IPv6  based  network  would  satisfy  the 
data  availability  and  timeliness  requirements  for  range  safety  after  the  change  to  using 
GPS  metric  tracking  for  all  vehicles. 

From  an  availability  point  of  view,  range  safety  data  is  less  than  8%  of  the 
network  data  load.  The  factors  treated  as  steady-state  background  traffic  place  a  much 
greater  demand  on  the  data  network  capacity.  This  background  traffic  is  estimated  to  be 
36%  of  the  available  network  capacity  using  the  legacy  systems  and  57%  if  various 
modernized  systems  (e.g.,  voice  over  IP,  IP  based  video)  are  used.  As  for  capacity  to  add 
and  remove  data  from  the  core,  range  safety  uses  at  most  13%  of  the  available  capacity, 
which  is  driven  by  large  volumes  of  telemetry  data.  Again  there  is  ample  bandwidth 
available  for  systems  like  voice  over  IP  and  IP  based  video. 

There  are  reasons  beyond  meeting  the  range  safety  requirements  that  make  the 
migration  to  an  IPv6  standard  a  reasonable  course  of  action.  The  network  is  important  to 
interoperability  and  the  ease  with  which  modernized  sensors  can  be  accepted  on  to  the 
range.  With  the  wide  acceptance  of  the  IP  packetized  data,  it  is  likely  that  modernized 
components  would  favor  the  IP  standard.  The  ROSA  radar,  voice  over  IP,  and  IP  based 
video  are  examples.  Additionally,  compliance  with  DoD  Joint  Technical  Architecture 
calls  for  using  IPv6  (FRAT,  2007).  Besides  the  interoperability  requirements,  there  is  a 
need  to  address  the  sustainability  of  the  legacy  network,  which  is  considered  to  be 
unsupportable  (Laird,  2008). 

Answering  research  question  2  (Question  2:  In  modernizing  the  range  data 
network,  is  it  more  advantageous  to  make  legacy  components  forward  compatible  or  to 
make  modern  components  backward  compatible?):  Currently,  the  range  uses  both 
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approaches  suggested  in  question  2.  Legacy  components  employ  middleware  for  use 
with  the  relatively  new  data  network  and  modem  components  are  backward  compatible 
to  legaey  data  formats  (e.g.,  ROSA  radars).  Since  eurrent  praetices  have  demonstrated 
the  feasibility  of  making  legacy  sensors  forward  compatible,  the  range  should  move 
toward  a  strategy  of  making  modern  systems  compatible  with  a  modern  network 
infrastmcture  rather  than  forcing  compatibility  to  legacy  formats.  Legacy  formats,  like 
the  240-bit  data  frame  are  not  amenable  to  transport  on  the  current  data  network,  whieh 
transfers  T-1  size  data  frames.  Defining  system  interfaces  that  produce  data  in  a  form 
that  can  be  transported  by  the  network,  irrespective  of  how  it  evolves,  is  an  important 
step  in  modernizing  the  range. 

B,  RECOMMENDATIONS 

The  baekward  compatibility  strategy  should  be  reviewed  with  a  systems 
perspective  starting  with  the  interface  control  documents.  Particular  attention  should  be 
paid  to  data  input  and  output  rates  and  formats.  If  a  devices  requires  input  in  a  legacy 
data  format,  it  needs  to  be  used  with  middleware  to  convert  data  from  the  format  used  by 
the  core  network,  because  the  legacy  formats  cannot  be  used  directly  on  the  network. 
Making  a  system  that  is  inherently  compatible  with  the  range  network  convert  its  output 
to  a  legacy  format  is  unnecessary  because  that  data  is  reformatted  for  transport  on  the 
network.  If  the  requirement  for  the  legacy  data  standards  is  driven  by  other  ranges  that 
need  to  interface  with  the  launeh  ranges,  the  issue  may  need  to  be  brought  to  the  Range 
Commanders’  Council.  Emphasis  should  be  on  putting  the  middleware  at  the  device  that 
consumes  legaey  formatted  data  rather  than  at  the  device  that  produces  it. 

C.  AREAS  OF  FURTHER  RESEARCH 

The  range  has  a  signifieant  network  bandwidth  demand  for  video  that  far  exceeds 
the  network  bandwidth  demands  of  the  range  safety  requirements  (Gillis,  2008).  The 
range  also  records  telemetry  data  for  latter  analysis  and  arehives  other  data.  Arguably  the 
range  is  basically  an  Automated  Information  System,  which  probably  led  to  the  ORD 
requirement  for  the  range  to  be  DoD  GIG  compliant.  (Headquarters  Air  Force  Space 
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Command,  DRSR,  2003,  Section  1.4. 3. 3).  The  range  is  also  a  real  time  sensor  network 
with  strict  range  safety  timing  requirements.  Can  these  functions  both  be  optimized  on 
the  same  network?  Does  the  AIS  need  for  accessibility  create  vulnerabilities  to  the 
sensor  net  side?  The  current  practice  of  using  a  dedicated  command  destruct  circuit 
seems  to  be  a  reaction  to  such  concerns. 

Another  consideration  is  the  extent  to  which  some  data,  like  telemetry  data,  is 
both  range  safety  and  customer  data.  For  some  operations  the  entire  telemetry  stream 
needs  to  be  handled  by  the  range  safety  systems  to  extract  the  data  they  need.  This  is  the 
same  telemetry  data  the  customer  wants.  The  Publish/Subscribe  model  appears  to  be  able 
to  handle  a  variety  of  subscriptions  with  a  hierarchy  of  priority.  This  may  allow  both 
functions  to  work  well  together  on  the  same  network,  especially  if  the  telemetry  data 
comes  from  the  vehicle  formatted  in  IP  packets.  The  correct  Quality  of  Service 
parameters  could  address  the  reliability  requirements  for  range  safety  and  the  large 
network  sized  for  AIS  functions  would  have  ample  performance. 

There  appears  to  be  room  for  improving  timeliness  by  examining  the  need  to 
maintain  legacy  communications  standards.  The  emphasis  should  be  on  interoperability 
with  the  network,  rather  than  between  the  devices  that  produce  data  and  the  ones  that 
consume  it.  Getting  data  from  one  to  the  other  demands  network  compatibility,  so  the 
interface  requirements  need  to  reflect  that.  Further  study  along  these  lines  should  be 
done  within  the  launch  range  and  among  all  the  ranges  that  need  to  interoperate. 
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